Spring Security April 2026: 7 CVEs Including Two Critical Authorization Bypasses

On April 21, 2026, the Spring Security team disclosed seven CVEs in a single advisory cycle and shipped fixes across Spring Security 6.5.10, 7.0.5, and 7.0-RC1, plus a coordinated update to Spring Authorization Server. The batch is unusual in two ways. First, severity is concentrated at the top: one Critical (CVSS 9.6) and three High (two CVSS 8.1 and one in the High band) sit alongside three Medium-rated issues. Second, the seven CVEs cluster cleanly into three failure modes, which is rare for a same-day batch and useful for triage.

This roundup walks through all seven CVEs in three clusters: authorization bypass, authentication weaknesses, and session integrity. It covers OSS fix versions for the supported branches, the EOL footprint that the patches do not reach, and the remediation options for teams running Spring Security 4.2.x, 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, or 6.4.x.

The seven CVEs covered are:

• CVE-2026-22752: Spring Authorization Server, Dynamic Client Registration metadata validation, CVSS 9.6 Critical
• CVE-2026-22753: Spring Security, servlet path not included in HttpSecurity#securityMatchers matching, CVSS 8.1 High
• CVE-2026-22754: Spring Security, servlet path not included in XML authorization rules, CVSS 8.1 High
• CVE-2026-22747: Spring Security, X.509 user impersonation via SubjectX500PrincipalExtractor, CVSS High
• CVE-2026-22746: Spring Security, DaoAuthenticationProvider timing-attack bypass, CVSS Medium
• CVE-2026-22748: Spring Security, JWT validation misconfiguration in NimbusJwtDecoder / withIssuerLocation, CVSS Medium
• CVE-2026-22751: Spring Security, TOCTOU race in JdbcOneTimeTokenService, CVSS Medium

‍

What Spring shipped on April 21, 2026

Spring Security released three coordinated patch lines:

The four EOL Spring Security branches in current production fleets (5.7.x, 5.8.x, 6.2.x, 6.3.x) and the three older EOL branches (4.2.x, 5.5.x, 6.4.x) do not receive these fixes from the upstream project. Several of the CVEs in this batch were introduced years before 7.0, so the EOL exposure is real, not theoretical.

A note on which CVEs affect which branches: not every CVE applies to every line. The servlet-path matching CVEs (22753, 22754) and the JWT validation issue (22748) reach back furthest, while the NimbusJwtDecoder code path was introduced in 5.2 and the JdbcOneTimeTokenService in 6.4. The detailed affected-versions matrix is in the patch matrix section near the end of this post.

‍

Cluster one: authorization bypass (CVE-2026-22752, CVE-2026-22753, CVE-2026-22754)

The authorization bypass cluster is the dangerous part of this batch and is the reason the April 21 patch line should not wait.

CVE-2026-22752: Spring Authorization Server, Dynamic Client Registration (CVSS 9.6 Critical)

The most severe CVE in the batch is in Spring Authorization Server. The Dynamic Client Registration endpoint (defined in RFC 7591) accepted client metadata fields without sufficient validation. Three concrete impacts have been publicly described:

1. Stored XSS via client metadata. Fields such as client_name, client_uri, logo_uri, and policy_uri were stored as registered client attributes. When rendered on consent pages or admin views without strict output encoding, attacker-controlled markup executed in the browser of any user reaching that page.
2. Privilege escalation via scope and grant_types manipulation. Insufficient validation on the scope and grant_types fields allowed a registering client to claim authorization grants the registering principal would not normally be entitled to. In deployments where registration is permitted at all (often gated to "trusted internal callers"), this collapsed the boundary between caller-defined identity and server-enforced policy.
3. SSRF via jwks_uri and redirect_uris. The server fetched jwks_uri during token validation. Without strict allowlisting on the URI scheme, host, and resolved IP, an attacker who could register a client could induce the authorization server to issue HTTP requests to arbitrary internal targets, including cloud metadata endpoints.

The CVSS 9.6 score reflects the combined surface: low attack complexity, low privileges required (anyone able to call the registration endpoint), and high impact on confidentiality, integrity, and availability with scope change.

If your deployment exposes Dynamic Client Registration on Spring Authorization Server at all, treat this CVE as a same-day patch.

CVE-2026-22753 and CVE-2026-22754: servlet path not included in security matchers (CVSS 8.1 High each)

These two CVEs share a root cause and differ only in configuration style. In both, Spring Security computed request matches without including the servlet path component when the application was deployed under a non-root servlet path mapping.

The result: a rule intended to require authentication on /admin/** could be bypassed by a request that resolved to /myservlet/admin/... under a servlet path of /myservlet, because the matcher saw /admin/... (the servlet-relative path) rather than the full request URI.

• CVE-2026-22753 affects Java configuration using HttpSecurity#securityMatchers and the related securityMatcher builder.
• CVE-2026-22754 affects equivalent rules expressed in XML configuration (<intercept-url pattern="...">).

The threat model is straightforward: any application that relies on path-based authorization rules and is deployed under a non-root servlet path is exposed. Default Spring Boot deployments using the embedded servlet container at the root path are not affected by this specific bypass, but applications deployed to a traditional servlet container with explicit context-path or servlet-path mapping should be patched.

This is the same class of bug as several historical Spring Security regressions: a request-attribute computation that was correct on its own but disagreed with what authorization rules expected. Defense-in-depth options (such as method-level @PreAuthorize on protected handlers) reduce blast radius but do not substitute for the patch.

‍

Cluster two: authentication weaknesses (CVE-2026-22746, CVE-2026-22747, CVE-2026-22748)

The authentication cluster is a mix of one High and two Mediums, all in code paths that touch identity establishment.

CVE-2026-22747: X.509 user impersonation via SubjectX500PrincipalExtractor (CVSS High)

SubjectX500PrincipalExtractor is a Spring Security utility that extracts a username from the Subject of an X.509 client certificate. The vulnerability is that the extractor accepted certain malformed or specially crafted Subject DNs that, when normalized, collapsed to the same string as a legitimate user's DN.

Exploitation requires the attacker to obtain a certificate that is trusted by the application's truststore. In many enterprise deployments, the truststore is intentionally permissive (an internal corporate CA, for example) and the Subject DN is the only field used to derive identity. In those deployments, an attacker who can issue a certificate (or compromise a CA) can impersonate any user simply by crafting the DN.

The patch tightens DN parsing and rejects ambiguous forms. The mitigation question is whether your X.509 authentication path treats the extracted username as authoritative without additional verification (such as a separate identity service lookup or a certificate fingerprint binding). If yes, this CVE is more impactful for your deployment than the score suggests.

CVE-2026-22746: DaoAuthenticationProvider timing-attack bypass (CVSS Medium)

DaoAuthenticationProvider short-circuited password verification when the supplied username did not match a known account. This produced an observable timing difference between "username does not exist" and "username exists, password is wrong."

In isolation, this is a low-severity issue. In combination with credential-stuffing tooling, it allows attackers to enumerate valid usernames before attempting passwords. The patch ensures a constant-time path is taken regardless of whether the user record was found.

The defense-in-depth control is rate limiting on the authentication endpoint. If your stack already enforces strict rate limits per source address, the practical exposure is small. If not, patch and add rate limiting; the CVE is a reminder that authentication endpoints leak information through latency, not just response codes.

CVE-2026-22748: NimbusJwtDecoder JWT validation misconfiguration (CVSS Medium)

NimbusJwtDecoder.withIssuerLocation(...) is a builder used by resource servers to validate JWTs against an OpenID Connect issuer. The vulnerability is that the builder did not install a JwtIssuerValidator by default in some configurations, even though the application code explicitly referenced an issuer URL.

The result: a JWT signed by the correct issuer's key but containing an iss claim that pointed to a different issuer was accepted as valid. In multi-tenant deployments where multiple issuers share signing infrastructure, this allowed cross-tenant token reuse.

The patch ensures that withIssuerLocation installs the issuer validator unconditionally. The compensating control is to call setJwtValidator(...) explicitly during decoder construction; the CVE record documents this as a workaround for teams that cannot patch immediately.

This issue has a "silent failure" character: validation that the developer believed was active was not, the application started cleanly, no warning appeared in logs, and tokens validated against the wrong issuer were accepted. It belongs to a broader pattern of Spring CVEs in this two-month window where defaults silently disabled security; that pattern is the subject of a separate post linked from the Spring CVE surge meta-post.

‍

Cluster three: session integrity (CVE-2026-22751)

CVE-2026-22751: TOCTOU race in JdbcOneTimeTokenService (CVSS Medium)

JdbcOneTimeTokenService is the JDBC-backed implementation of the Spring Security OTT (one-time token) service introduced in 6.4. The vulnerability is a time-of-check / time-of-use race between the token consumption query and the token deletion query.

Under concurrent requests with the same token, two threads could both pass the "is this token valid?" check before either reached the "delete this token" step. Both requests then succeeded, defeating the single-use guarantee of a one-time token.

In practical terms, this allows an attacker who has captured a one-time token (typically a passwordless login link or a magic link in an email) to replay it concurrently and produce two authenticated sessions. The window is small (the gap between SELECT and DELETE in the JDBC implementation), but it is reachable from a single attacker workstation issuing parallel HTTP requests.

The patch atomicizes the consume-and-delete operation. There is no compensating control short of disabling OTT or adding application-level locking, both of which are heavier than just patching.

‍

Affected versions and EOL footprint

The seven CVEs do not all share the same affected-version range. The matrix below consolidates the public advisory data:

The branches that are out of OSS support and therefore receive no upstream patch for any of these seven CVEs are: Spring Security 4.2.x, 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, and 6.4.x. Teams running these branches without a commercial patch stream are exposed to whichever subset of the seven applies to their version, with no upstream remediation available.

‍

Patch matrix and OSS fix versions versus NES coverage

For deployments that cannot upgrade in the short term, the defense-in-depth options worth applying immediately are:

• Disable Dynamic Client Registration on Spring Authorization Server unless it is required (this neutralizes CVE-2026-22752 entirely)
• Add strict rate limiting on authentication endpoints (reduces practical exposure of CVE-2026-22746)
• Add an explicit setJwtValidator(...) call when constructing NimbusJwtDecoder instances (compensating control for CVE-2026-22748)
• For X.509-authenticated applications, layer a second identity check beyond the extracted DN (compensating for CVE-2026-22747)

These are mitigations, not fixes. The seven CVEs require code changes that only a patched binary delivers.

‍

How regulated enterprises are handling Spring Security exposure

For enterprises with formal security review and external audit, the April 21 batch is exactly the kind of disclosure cycle where the gap between OSS support and what is actually running in production becomes visible. A global financial services customer running a Spring Security footprint across multiple business units worked with HeroDevs to close that gap on EOL Spring branches that the upstream project no longer patches; that engagement is summarized in the Proactive Security for Mission-Critical Systems case study, and the same shape of risk applies to any organization where audit findings reference Spring Security CVEs against branches their internal upgrade roadmap will not reach in the near term.

For teams with EU Cyber Resilience Act obligations coming into effect in September 2026, this batch is also a useful forcing function. CRA Annex I requires that products with digital elements be made available without known exploitable vulnerabilities. A Spring Security 6.3 deployment with no patch path for CVE-2026-22752, CVE-2026-22753, or CVE-2026-22747 will not meet that standard once the enforcement window opens. Either the version moves forward, or the patches arrive through a commercial stream.

‍

Related CVEs

• CVE-2026-22732: The March 19 Spring Security headers regression, covered in the deep dive on silently dropped HTTP security headers
• CVE-2026-22731 and CVE-2026-22733: The March Spring Boot Actuator authentication bypasses, covered in the deep dive on enterprise Actuator exposure
• The March 2026 Spring CVE roundup covering the prior month's six-CVE batch
• Spring CVEs Surge in 2026 for the cross-batch trend analysis

‍

Taking action

The April 21 Spring Security batch is a high-density disclosure cycle: seven CVEs, three failure modes, and at least four severities ranging from CVSS 9.6 down to 4. The supported branches have a clear upgrade path through 6.5.10 and 7.0.5. The seven EOL branches do not.

If your organization runs Spring Security on 4.2.x, 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, or 6.4.x and a multi-quarter upgrade to 6.5 or 7.0 is not realistic for the affected applications, HeroDevs NES for Spring delivers a secure, drop-in replacement that resolves all seven of the CVEs disclosed on April 21, 2026, plus the rest of the March and April 2026 Spring disclosure window. The remediation arrives through your existing dependency-management pipeline and does not require an emergency major-version upgrade.

For teams under EU CRA scrutiny, the September 2026 enforcement window is the point at which "we cannot upgrade to 6.5 or 7.0 yet" stops being an acceptable answer for known-exploitable CVEs in shipped products. The patch path is the question; the deadline is no longer flexible.