NVIDIA Triton's path traversal vulnerability (CVE-2026-47606) represents an ergonomic trap that the ML tooling ecosystem has been building toward for years: the inference server accepts absolute paths without validating them, placing security boundary enforcement on every operator who configures a model load. This isn't a novel vulnerability class—path traversal has been understood since the 1990s—but it's been reselected repeatedly as vendors compete on deployment convenience. Operators file tickets about 'inconvenient restrictions'; vendors strip validation; the attack surface accumulates. That's the structural pattern, and it's why this CVE shouldn't be evaluated on EPSS alone.
The blast radius is the priority metric here. Inference servers sit at the convergence of proprietary models, training data pipelines, and cloud credentials (often service account keys with broad IAM permissions). Compromising Triton doesn't just mean reading files on one host—it means potential lateral movement into S3/GCS buckets, GPU compute resources, and every system that the inference server's credentials can reach. This is a high-value target sitting on infrastructure that typically has looser security posture than production application servers, because ML engineers frequently deploy Triton without security team involvement.
Your immediate actions: assume the inference server WILL be compromised and contain the blast radius. Apply container seccomp profiles that block file operations outside expected model paths. Run Triton in a namespace with no access to credential mount points or training data stores. Restrict IAM roles attached to any service account the inference server uses—grant only the minimum read permissions it needs for inference, not bucket-level access. The patch adds path validation; deploy it. But understand that patch-to-deployment lag in ML infrastructure often spans quarters, not days, so architectural containment is your interim defense and your last line of defense.