What is the CVSS score of CVE-2026-40995?

CVE-2026-40995 has a CVSS 3.1 base score of 5.4 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-40995?

Yes, a patch is available for CVE-2026-40995. Update the affected software to the latest version immediately.

Spring Web Services CVE-2026-40995

EUVD-2026-36205 MEDIUM

Improper Authentication (CWE-287)

2026-06-11 vmware

GHSA-6mfm-98wv-32wm

Authentication Bypass Java Spring Web Services

5.4

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

5.4 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

vuln.today AI

5.4 MEDIUM

Certificate possession is equivalent to low-privilege credential (PR:L); scope is unchanged and impact is bounded to authenticated service resources (C:L/I:L/A:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Patch available

Jun 11, 2026 - 08:01 EUVD

Analysis Generated

Jun 11, 2026 - 07:06 vuln.today

DescriptionCVE.org

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.

AnalysisAI

X509AuthenticationProvider in Spring Web Services issues fully authenticated tokens from client certificates without enforcing Spring Security's account lifecycle checks, meaning disabled, locked, expired, or credentials-expired accounts can successfully authenticate. This affects all maintained release branches from 3.1.0 through 5.0.1 and was reported by VMware, the Spring project maintainer. No public exploit or CISA KEV listing has been identified at time of analysis, but the bypass is meaningful in environments that rely on account-disablement as the primary deprovisioning control rather than certificate revocation.

Technical ContextAI

Spring Web Services (Spring-WS) is a Java contract-first SOAP framework built atop the broader Spring ecosystem. Client X.509 certificate authentication in Spring-WS flows through X509AuthenticationProvider, which maps a presented certificate to a UserDetails object. Under standard Spring Security design, any UserDetails retrieval is subject to AccountStatusUserDetailsChecker, which enforces four lifecycle predicates: account enabled, account non-locked, account non-expired, and credentials non-expired. CWE-287 (Improper Authentication) captures the root cause: the provider short-circuits this checker and emits a fully authenticated X509AuthenticationToken the moment a valid certificate-to-UserDetails mapping is resolved, bypassing the enforcement gate entirely. The affected CPE is cpe:2.3:a:spring:spring_web_services:*:*:*:*:*:*:*:*, spanning versions 3.1.0 through 5.0.1 across four release branches.

RemediationAI

The primary remediation is to upgrade to a fixed version of Spring Web Services once patched releases are confirmed via the vendor advisory at https://spring.io/security/cve-2026-40995. No exact fixed version number is available in the current intelligence - the advisory must be consulted directly for the specific target version per affected branch. As an immediate compensating control prior to patching, organizations should ensure that user deprovisioning workflows include explicit certificate revocation through CRL updates or OCSP stapling in addition to account disablement in the UserDetails store; this prevents the TLS layer from presenting the certificate to the application at all, neutralizing the bypass. A second workaround, if mutual TLS certificate authentication via X509AuthenticationProvider is not strictly required by the application, is to disable that authentication provider in the Spring Security configuration - this eliminates the vulnerable code path entirely but will break all certificate-based login flows for legitimate users. Both compensating controls have operational trade-offs that should be evaluated against the deployment's authentication architecture before implementation.