NeuVector vulnerabilities

Improper parameter handling in NeuVector allows any authenticated user with namespaced Runtime Policies (write) permission or anyone with access to NeuVector’s internal gRPC certificate key pair to inject OS commands in the privileged enforcer container, leading to complete compromise of the worker node.

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.

The NeuVector JWT verifier accepts noncanonical Base64URL encodings of the same RSA signature field. An attacker holding a valid JWT that has not expired, but was logged out of NeuVector, can continue using the non-expired token with equivalent spelling of the RSA signature field until the token validity expires.

Authorised users of outside applications behind the same corporate identity provider (IdP), such as a wiki, ticketing system, or expenses tool, can log into their system via SAML SSO. If that assertion is presented to NeuVector, NeuVector accepts it because the only thing distinguishing an assertion for NeuVector from an assertion for the wiki is the element, and the NotInAudience warning that reports the mismatch is never read.

NeuVector through 5.4.9 can potentially leak information from the manager /network/graph API due to missing authentication and cached data containing sensitive information.

NeuVector used a hard-coded cryptographic key embedded in the source code. At compilation time, the key value was replaced with the secret key value and used to encrypt sensitive configurations when NeuVector stores the data.