MEDIUM 5.4

CVE-2026-40995: Spring Web Services X509 Authentication Bypass Accounting Lifecycle Checks

Spring Web Services has a vulnerability in its X509 certificate authentication handler that bypasses Spring Security's standard account status checks. When a user presents a valid certificate that maps to a known user account, the system authenticates them without verifying whether that account is disabled, locked, expired, or has expired credentials. This means someone with a legitimate certificate could gain access even if their account should be inactive.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.4 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Weaknesses (CWE)
CWE-287
Affected products
0 configuration(s)
Published / Modified
2026-06-11 / 2026-06-23

NVD description (verbatim)

X509AuthenticationProvider could issue a fully authenticated X509AuthenticationToken when a presented certificate mapped to UserDetails, without applying Spring Security's standard account lifecycle checks (disabled, locked, expired, or credentials-expired accounts). Affected versions: Spring Web Services 5.0.0 through 5.0.1; 4.1.0 through 4.1.3; 4.0.0 through 4.0.18; 3.1.0 through 3.1.8.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The X509AuthenticationProvider in Spring Web Services fails to invoke Spring Security's standard account lifecycle validation methods when processing X509AuthenticationToken objects. After mapping a presented certificate to UserDetails, the provider issues a fully authenticated token without calling the appropriate checks that verify account status flags (enabled, accountNonLocked, accountNonExpired, credentialsNonExpired). This allows authentication to succeed for accounts that should be denied access due to administrative lockout, expiration, or credential age policies.

Business impact

Organizations relying on certificate-based authentication with Spring Web Services may unexpectedly grant access to users whose accounts have been administratively disabled or locked. This could expose APIs and web services to former employees or compromised certificate holders whose accounts were deactivated but whose certificates remain valid. Compliance frameworks requiring revocation of inactive user access may be violated, and incident response efforts could be complicated if disabled accounts can still authenticate via certificate.

Affected systems

Spring Web Services versions 3.1.0 through 3.1.8, 4.0.0 through 4.0.18, 4.1.0 through 4.1.3, and 5.0.0 through 5.0.1 are affected. Any deployment using X509-based authentication with these versions should be considered at risk. Systems using other authentication mechanisms in Spring Web Services are not affected by this specific flaw.

Exploitability

Exploitation requires an attacker to possess a valid X509 certificate that maps to a user account in the system. The attacker does not need to know passwords or bypass additional authentication factors. The vulnerability is straightforward to exploit once a certificate is obtained—authentication will succeed immediately without requiring interaction with disabled accounts or triggering alerts tied to standard account validation. The CVSS vector (AV:N/AC:L/PR:L) indicates network accessibility and low attack complexity, with low privilege required because the attacker must have a valid certificate identity.

Remediation

Apply security updates from Spring Web Services that restore standard account lifecycle checks to the X509AuthenticationProvider. Review and update your Spring Web Services deployments to the patched versions. Organizations should verify that patches are available and deployed in all environments using X509 authentication. Additionally, conduct a review of active certificates and disable or revoke any that correspond to inactive or locked user accounts.

Patch guidance

Consult the official Spring Web Services security advisories and release notes for patched versions addressing CVE-2026-40995. Patches should be available for the 3.1.x, 4.0.x, 4.1.x, and 5.0.x release lines. Before patching, test in a non-production environment to ensure compatibility with your certificate validation and account management policies. Verify that the patched version re-enables the account lifecycle checks and that authentication denies access for disabled or locked accounts, even with valid certificates.

Detection guidance

Monitor authentication logs for successful certificate-based logins to accounts that should be disabled, locked, or have expired credentials. Implement alerting if X509AuthenticationProvider issues tokens for accounts with non-standard status flags. Review certificate mappings and validate that active certificates correspond only to active user accounts. Check for unexpected authentications from former employees or revoked users. Log analysis should correlate X509 certificate subject information with account status at the time of authentication.

Why prioritize this

Although the CVSS score is MEDIUM (5.4), this vulnerability poses a meaningful risk because it directly undermines access control decisions made by system administrators. Any environment using certificate authentication must ensure that account lifecycle policies are enforced; bypassing them could lead to unauthorized access by deactivated users. Organizations with strict access revocation requirements or those handling sensitive data should prioritize patching this issue promptly, particularly if they cannot immediately verify that all disabled accounts have had their certificates revoked.

Risk score, explained

The CVSS 3.1 score of 5.4 reflects a network-accessible flaw with low attack complexity and low privileges required (the attacker must have a valid certificate). The impact is limited to confidentiality and integrity (no availability impact), and the scope is unchanged. The score appropriately captures that while the vulnerability is exploitable, it requires prior possession of a valid certificate and affects a subset of deployments using X509 authentication. However, the score does not fully weight the organizational risk of bypassing deliberate account access controls, which may justify elevated priority in your risk model.

Frequently asked questions

Does this vulnerability require the attacker to have credentials or additional knowledge?

No. The attacker only needs to possess a valid X509 certificate that the system recognizes and maps to a user account. No password, multi-factor authentication code, or other credential is required. The vulnerability bypasses the normal account status checks that would deny access to disabled or locked accounts.

Will patching break my existing certificate authentication setup?

Patching restores standard Spring Security account lifecycle checks to X509 authentication. If your account management practices are sound—that is, you revoke or disable certificates for locked or inactive accounts—patching should have no operational impact. However, if you have active certificates for accounts that are currently locked or disabled, those authentications will fail after patching. Review your certificate-to-account mappings before deploying patches.

Which authentication methods are not affected by this vulnerability?

This vulnerability is specific to X509 certificate-based authentication via Spring Web Services. Other authentication mechanisms supported by Spring Security (username/password, OAuth 2, SAML, LDAP, etc.) are not affected by this flaw. However, if your deployment uses X509 as part of a multi-factor setup, ensure all components properly enforce account status.

How can I tell if this vulnerability has been exploited in my environment?

Look for successful authentication events from accounts that are currently disabled, locked, or expired. Compare X509 certificate subject information in authentication logs against your user account status database. If you find matches, investigate whether those authentications were authorized. Also review recent changes to certificate mappings or authentication configurations that might indicate tampering.

This analysis is provided for informational purposes to support security decision-making. Verify all remediation and patch information against official vendor advisories and release notes before implementation. CVSS scores and vulnerability classifications are based on the provided data; your organization's risk assessment may differ based on deployment context, threat model, and compensating controls. No exploit code or weaponized proof-of-concept is provided or endorsed. Always test patches in non-production environments before broad deployment. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).