CVE-2026-40995 Overview
CVE-2026-40995 is an authentication weakness in Spring Web Services. The X509AuthenticationProvider issues a fully authenticated X509AuthenticationToken when a presented certificate maps to a UserDetails object. The provider does not apply Spring Security's standard account lifecycle checks. Accounts that are disabled, locked, expired, or have expired credentials can still authenticate successfully through X.509 client certificate flows. The flaw is classified under [CWE-287] (Improper Authentication) and affects Spring Web Services 5.0.0–5.0.1, 4.1.0–4.1.3, 4.0.0–4.0.18, and 3.1.0–3.1.8.
Critical Impact
Revoked or disabled user accounts retain access to Spring Web Services endpoints when authenticating with X.509 client certificates, undermining account deactivation as a security control.
Affected Products
- Spring Web Services 5.0.0 through 5.0.1
- Spring Web Services 4.1.0 through 4.1.3
- Spring Web Services 4.0.0 through 4.0.18 and 3.1.0 through 3.1.8
Discovery Timeline
- 2026-06-11 - CVE-2026-40995 published to NVD
- 2026-06-11 - Last updated in NVD database
Technical Details for CVE-2026-40995
Vulnerability Analysis
Spring Security defines a contract for authentication providers that consume UserDetails. Implementations are expected to invoke a UserDetailsChecker such as AccountStatusUserDetailsChecker before issuing an authenticated token. These checks evaluate the isEnabled(), isAccountNonLocked(), isAccountNonExpired(), and isCredentialsNonExpired() flags on the resolved UserDetails. The Spring Web Services X509AuthenticationProvider skips this step. When a client presents a valid X.509 certificate and the configured X509AuthoritiesPopulator resolves a UserDetails instance, the provider constructs and returns an authenticated X509AuthenticationToken directly. Administrative changes intended to revoke access, such as setting enabled=false in the user store or marking the account locked, have no effect on subsequent X.509 authentications. The vulnerability sits in the authentication layer, so downstream authorization decisions operate on a token that should never have been issued.
Root Cause
The root cause is a missing call to a UserDetailsChecker inside X509AuthenticationProvider. The provider authenticates based solely on certificate-to-principal mapping and does not consult the account status flags exposed by UserDetails. This deviates from the behavior of DaoAuthenticationProvider and other standard providers in Spring Security.
Attack Vector
An attacker requires a previously issued client certificate that still maps to a known principal in the UserDetails store. The certificate does not need to be revoked at the PKI layer for this issue to apply. Network access to the X.509-protected Spring Web Services endpoint is sufficient. The attacker authenticates over TLS with mutual authentication, and the server accepts the request even when the corresponding account has been disabled, locked, or expired. The flaw enables continued access for terminated users, compromised insiders whose accounts have been disabled, or holders of certificates that should have been retired alongside account lifecycle events. See the Spring Security Advisory for technical details.
Detection Methods for CVE-2026-40995
Indicators of Compromise
- Successful X.509 authentication events for principals whose UserDetails records are marked disabled, locked, or expired in the backing identity store.
- Web service access logs showing activity from accounts that have been administratively offboarded but never had their client certificates revoked.
- Mismatches between identity management deactivation timestamps and continued application access from the same principal.
Detection Strategies
- Correlate Spring Web Services access logs with identity store status flags to identify authentications that should have been rejected.
- Inventory deployments and verify the running spring-ws-security version against the affected ranges (5.0.0–5.0.1, 4.1.0–4.1.3, 4.0.0–4.0.18, 3.1.0–3.1.8).
- Audit X509AuthenticationProvider bean configuration to confirm whether a custom UserDetailsChecker has been wired in.
Monitoring Recommendations
- Alert on authentication events from accounts that identity governance systems report as deactivated.
- Track client certificate usage and flag certificates that remain active beyond an account's offboarding date.
- Forward Spring Web Services authentication logs to a SIEM and join them with HR or IAM lifecycle events.
How to Mitigate CVE-2026-40995
Immediate Actions Required
- Upgrade Spring Web Services to a fixed release as documented in the Spring Security Advisory.
- Revoke client certificates associated with disabled, locked, or expired accounts at the PKI layer until patches are applied.
- Audit UserDetails records and remove or fully deprovision accounts that should no longer authenticate.
Patch Information
Upgrade to a patched version of Spring Web Services beyond the affected ranges 5.0.0–5.0.1, 4.1.0–4.1.3, 4.0.0–4.0.18, and 3.1.0–3.1.8. Refer to the Spring Security Advisory for the specific fixed releases and release notes.
Workarounds
- Configure X509AuthenticationProvider with an explicit UserDetailsChecker, such as AccountStatusUserDetailsChecker, to enforce account status checks during authentication.
- Implement a custom AuthenticationSuccessHandler or post-authentication filter that re-validates isEnabled, isAccountNonLocked, isAccountNonExpired, and isCredentialsNonExpired before granting access.
- Maintain strict certificate revocation procedures tied to account offboarding so that disabled accounts cannot present usable certificates.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
