CVE-2026-78425 in NeuVector
Summary
by MITRE • 09/17/2026
Authorised users of outside applications behind the same corporate identity provider (IdP), for example, a wiki, a ticketing system, an expenses tool, or anything they legitimately hold an account on can log into their system via SAML SSO. The IdP issues an assertion to them. 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability described constitutes a critical authentication bypass within NeuVector due to improper validation of SAML assertions issued by an Identity Provider. In standard Security Assertion Markup Language implementations, when a user authenticates via Single Sign-On, the IdP generates a signed assertion containing attributes about the user and metadata specifying which service provider is intended to receive it. This target audience is typically defined in the AudienceRestriction element or similar constructs within the SAML response. The core technical flaw lies in NeuVector's failure to enforce strict audience validation. Specifically, while the system may generate a warning indicating that the assertion was not intended for its specific entity ID, this check is non-enforcing and effectively ignored during the authentication decision process. Consequently, any validly signed SAML assertion issued by the corporate Identity Provider for any other application behind that same IdP can be replayed against NeuVector to gain unauthorized access.
This flaw represents a classic case of insufficient validation of security tokens, allowing attackers who have compromised credentials or control over an account in one legitimate service within the organization's ecosystem to pivot into the container security platform. For instance, if an attacker gains access to a corporate wiki or ticketing system through phishing or credential stuffing, they can extract the SAML assertion issued during their login session. By presenting this assertion directly to NeuVector’s authentication endpoint, the system accepts it as valid because it lacks the logic to verify that the audience restriction matches its own entity identifier. This bypasses multi-factor authentication and other security controls configured within NeuVector, effectively granting the attacker full administrative or user-level access depending on how their identity is mapped in the IdP.
From a risk perspective, this vulnerability aligns with CWE-287, which covers Improper Authentication, specifically regarding the failure to verify intended recipients of authentication tokens. It also relates closely to CWE-345, Insufficient Verification of Data Authenticity, as the system fails to validate that the token was meant for its specific context. In terms of MITRE ATT&CK framework mapping, this behavior facilitates Initial Access through SAML-based attacks and potentially Privilege Escalation if the mapped user has elevated permissions within NeuVector. The operational impact is severe because it undermines the trust boundary between different applications sharing a common identity provider. An attacker does not need to break cryptographic signatures or exploit buffer overflows; they simply leverage the legitimate authentication flow of another application, exploiting the lax validation logic in the target system.
Mitigation strategies must focus on enforcing strict audience restriction checks within the SAML integration module. NeuVector should be updated to parse the AudienceRestriction element from incoming assertions and explicitly verify that it contains its own entity ID or matches a predefined list of trusted audiences for this specific service instance. If no such match is found, the authentication request must be rejected immediately with an appropriate error code rather than issuing a warning. Additionally, implementing strict binding validation to ensure assertions are only accepted via intended protocols can add another layer of defense. Organizations relying on NeuVector should monitor IdP logs for unusual assertion issuance patterns and consider temporarily disabling SAML integration if patches are not yet available, while enforcing alternative authentication methods such as local accounts with strong password policies or API key restrictions until the vulnerability is remediated.