CVE-2026-47838

What it actually does

The flaw affects applications that use Spring Security X.509 client-certificate authentication with SubjectDnX509PrincipalExtractor to derive the application username from a certificate Subject DN common name (CN). Certain malformed or carefully encoded CN values can be parsed incorrectly, causing the application to authenticate the certificate holder as a different username than intended. If the attacker can obtain or present a certificate trusted by the application’s client-certificate trust chain, this can result in user impersonation and unauthorized access to data or functions belonging to the misidentified user. Affected Spring Security branches include 5.7.0-5.7.24, 5.8.0-5.8.26, 6.3.0-6.3.17, 6.4.0-6.4.17, and 6.5.0-6.5.10.

Why it matters to the business

Organizations using Spring Security for mutual TLS or certificate-based login could allow a user with a valid client certificate to be treated as another user. The primary business risk is unauthorized access to sensitive records, privileged workflows, or administrative capabilities tied to the impersonated account. The CVSS score is moderate-high, but exploitation complexity is high and EPSS is currently very low, with no known CISA KEV listing or public exploit maturity reported; nevertheless, systems that rely on certificate CN values for identity should prioritize remediation because successful exploitation directly undermines authentication and accountability.

How an attack unfolds

An attacker first needs access to a client certificate that is accepted by the target application’s trust configuration, such as through legitimate enrollment, compromise of a certificate, or abuse of a permissive internal certificate authority process. The attacker then crafts or obtains a certificate whose Subject DN CN contains malformed, escaped, or ambiguous values that are interpreted differently by certificate tooling and Spring Security’s SubjectDnX509PrincipalExtractor. When the attacker connects to the application over a path requiring X.509 authentication, the TLS layer accepts the certificate, but the application extracts the wrong username from the Subject DN. Spring Security then builds an authenticated principal for the unintended username, allowing the attacker to act as that user wherever authorization decisions rely on the extracted username.

How to fix it

Upgrade Spring Security to a fixed release outside the affected ranges. Based on the affected version boundaries, use the vendor-fixed version for the relevant branch, such as 5.7.25 or later, 5.8.27 or later, 6.3.18 or later, 6.4.18 or later, or 6.5.11 or later, if available for the deployed branch. If an upgrade cannot be applied immediately, avoid deriving identity directly from free-form certificate CN values. Prefer a custom AuthenticationUserDetailsService or principal extractor that validates the full certificate subject using standards-compliant parsing and enforces a strict allowlist of expected identity formats. Consider binding users to certificate serial number, issuer DN, Subject Alternative Name, or a certificate fingerprint instead of CN alone. Restrict certificate issuance so users cannot choose arbitrary CN values, and ensure the client-certificate trust store contains only intended issuing CAs.

How to confirm the fix worked

Inventory applications and dependencies for Spring Security versions in the affected ranges and confirm whether X.509 authentication is enabled. Review application security configuration for x509(), X509AuthenticationFilter, SubjectDnX509PrincipalExtractor, or custom principal extraction from certificate Subject DN CN. After upgrading, confirm the resolved runtime dependency versions are outside the affected ranges using build tooling such as Maven dependency:tree, Gradle dependencies, SBOM scans, or application startup dependency reports. Functionally validate the fix by testing certificates with normal CN values and malformed or escaped CN patterns, confirming that ambiguous values are rejected or mapped only to the intended principal. Also verify that authentication logs record certificate issuer, serial number, fingerprint, and mapped username so future investigations can correlate certificate identity to application identity.

Typical attack path

1. Identify an application endpoint that uses client-certificate or mutual TLS authentication backed by Spring Security X.509 authentication.
2. Confirm that the application maps identity from the certificate Subject DN CN using SubjectDnX509PrincipalExtractor or equivalent default CN extraction behavior.
3. Obtain a client certificate trusted by the application’s configured certificate authority or trust store.
4. Create or request a certificate with a malformed, escaped, or ambiguous CN value designed to be parsed as a different username by the vulnerable extractor.
5. Authenticate to the application using the crafted certificate.
6. Gain an authenticated session or request context associated with the impersonated user.
7. Access data or perform actions permitted to the impersonated account.

How to detect it

Look for evidence that client certificates were accepted while the application mapped them to unexpected usernames. Useful log sources include application authentication logs, Spring Security debug logs, reverse proxy or ingress mutual TLS logs, web server TLS client-certificate logs, certificate authority issuance records, identity provider audit logs, and endpoint or container logs for deployed application versions. Investigate authentication events where one certificate fingerprint or serial number appears with more than one username, where a certificate CN contains unusual escaping, embedded delimiters, repeated CN attributes, quotes, leading or trailing whitespace, control characters, or encoded characters, or where the application username differs from the canonical certificate identity recorded by the TLS terminator. Also review certificate issuance records for recently created certificates with malformed Subject DN values or CNs resembling other users. There are no widely reported public exploitation indicators for this issue, so detection should focus on behavioral inconsistencies in certificate-to-user mapping rather than known attacker infrastructure.

• org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor
• SubjectDnX509PrincipalExtractor
• org.springframework.security.web.authentication.preauth.x509.X509AuthenticationFilter
• X509AuthenticationFilter
• javax.servlet.request.X509Certificate
• SSL_CLIENT_S_DN
• SSL_CLIENT_CERT
• PreAuthenticatedAuthenticationToken
• spring-security-web-5.7.
• spring-security-web-5.8.
• spring-security-web-6.3.
• spring-security-web-6.4.
• spring-security-web-6.5.
• spring-security-config-5.7.
• spring-security-config-5.8.
• spring-security-config-6.3.
• spring-security-config-6.4.
• spring-security-config-6.5.
• <x509
• x509()
• subject-principal-regex
• CN=

What your security team should do

• Prioritize patching externally reachable or high-privilege applications that use Spring Security X.509 client-certificate authentication and map users from certificate CN values.
• Inventory all services running Spring Security 5.7.x, 5.8.x, 6.3.x, 6.4.x, or 6.5.x and identify those using x509() authentication or SubjectDnX509PrincipalExtractor.
• Upgrade to the vendor-fixed Spring Security release for each maintained branch and redeploy affected applications.
• Temporarily restrict access to certificate-authenticated endpoints to trusted networks or gateways until remediation is complete.
• Audit certificate authority enrollment policies to prevent arbitrary, user-controlled, malformed, or duplicate CN values.
• Review recent authentication logs for cases where the same certificate fingerprint, serial number, or issuer was associated with multiple application usernames.
• Add logging for certificate subject, issuer, serial number, fingerprint, and mapped principal where legally and operationally appropriate.
• Prefer identity mapping from SAN, issuer plus serial number, or certificate fingerprint rather than parsing free-form Subject DN CN values.