NeuVector EUVD-2026-81416

Requires NeuVector deployed as a Kubernetes admission controller with admission deny rules configured (otherwise there is nothing to bypass), AND an attacker with cluster RBAC permission to create workloads (pods/deployments) - PR:L, an authenticated insider or compromised deploy credential. The concrete trigger is naming the container image path to match one of three hardcoded service-mesh sidecar images that the webhook treats as an implicit exclusion; the image path is fully workload-author-controlled. Limiting factors: no anonymous/unauthenticated path, no impact where NeuVector deny policies are not enforced, and the technique only evades NeuVector's own admission checks (does not itself grant code execution or data access).

This is a genuine but low-to-moderate-severity security-control bypass, not a critical flaw. The vendor CVSS of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) correctly reflects that exploitation requires an authenticated cluster user (PR:L) with rights to deploy workloads, and there is no confidentiality impact. However, the vendor's choice of A:L (availability) is questionable: the actual harm is that admission deny rules are silently bypassed, which is an integrity/policy-enforcement failure - an attacker uses it to deploy workloads that policy should have blocked, so I:L is more defensible than A:L (score stays ~4.3 either way). No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so real-world exploitation pressure is low. The technique is trivial once you can deploy workloads (just name your image path after a hardcoded sidecar), so the barrier is entirely the PR:L requirement rather than technical difficulty. Net: a real defense-in-depth weakness worth patching in security-conscious Kubernetes environments, but not an urgent internet-facing emergency - its impact is realized only by an already-authenticated insider or a compromised deploy credential circumventing NeuVector's own guardrails.

An authenticated user (or compromised service account) with permission to create pods/deployments in a cluster protected by NeuVector admission deny rules crafts a workload whose container image path matches one of the three hardcoded service-mesh sidecar image names. The NeuVector admission webhook then silently skips policy evaluation for that container, allowing an otherwise-denied (e.g., non-compliant or malicious) workload to be admitted. No public exploit code is identified at time of analysis, though the technique is described precisely in the advisory.