CVE-2026-78427 in NeuVector
Summary
by MITRE • 09/17/2026
The NeuVector admission webhook silently excludes containers from policy evaluation when their image path matches one of three hardcoded service mesh sidecar images. Since the image path is entirely controlled by the workload author, any user capable of deploying workloads can evade admission deny rules simply by naming their image path after one of these sidecar images.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability described involves a critical flaw in the NeuVector admission webhook logic, specifically regarding how it handles policy evaluation for containerized workloads. The core issue stems from hardcoded exceptions within the security control mechanism that automatically bypasses validation checks for specific image paths associated with service mesh sidecars. This design choice was likely intended to facilitate seamless integration of popular service mesh technologies like Istio or Linkerd by preventing their injected proxy containers from being blocked by strict network policies during deployment. However, this implementation creates a significant blind spot because the check relies solely on matching the container image path against a static list rather than verifying the actual identity or trustworthiness of the workload author.
From a technical perspective, the flaw represents an insecure default configuration combined with insufficient input validation regarding resource ownership. The admission webhook operates as a gatekeeper in Kubernetes clusters, intercepting creation requests to enforce security policies such as network segmentation and pod restrictions. When a user submits a deployment manifest, the webhook inspects the container image paths defined within it. If any of these paths match one of the three hardcoded service mesh identifiers, the webhook silently skips further policy evaluation for that workload. This behavior effectively grants an unconditional pass to any resource claiming to be part of those specific sidecar infrastructures, regardless of whether the user has legitimate authorization or intent consistent with standard service mesh operations.
The operational impact of this vulnerability is severe, as it allows unauthorized users to completely evade admission deny rules by simply manipulating metadata in their workload definitions. Since container image paths are fully controlled by the entity deploying the workloads, an attacker can craft a malicious deployment manifest that references one of the exempted sidecar images while actually pulling and executing arbitrary code from any other registry or source. This technique enables privilege escalation scenarios where users who would otherwise be blocked from creating pods due to restrictive policies can successfully deploy them. Once deployed, these containers may have access to sensitive network segments, internal services, or data stores that were intended to remain isolated by the cluster's security posture.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if viewed as a form of hard-coded bypass logic, though it is more accurately categorized under CWE-605 Multiple Bindings which refers to binding multiple names or identifiers to the same resource in an insecure manner. In terms of MITRE ATT&CK for Kubernetes, this maps directly to T1499 Endpoint Denial of Service if used disruptively, but more critically to T1608 Install Resilience Script when considering persistence mechanisms and potentially T1525 Implant Internal Image if the attacker uses internal registries. The ability to bypass admission controls undermines the fundamental principle of least privilege enforced by Kubernetes RBAC and network policies.
Mitigation strategies must focus on removing reliance on static image path matching for exemption logic. Administrators should configure the webhook to validate not just the image name but also verify that the requesting user or service account has explicit permissions associated with those specific sidecar roles, perhaps through role-based access control checks within the admission controller itself. Alternatively, implementing a dynamic allowlist based on verified namespaces or labels rather than hardcoded strings would prevent arbitrary users from exploiting this bypass. Regular auditing of webhook configurations and testing policy enforcement against various workload types is essential to ensure that security controls remain robust against evasion techniques derived from misconfigured exemptions.