The CVE you least want sitting in your auth layer

Spring Security cannot be upgraded on its own. Its version is tied to the Spring Framework and Spring Boot lines around it, so an application on Framework 5.3 or Boot 2.7 stays on Security 5.x until the whole stack moves. Every authentication bypass, CSRF or authorization advisory disclosed after December 2023 has no upstream patch path for 5.x.

The move to Spring Security 6 is also bigger than a version bump. It brings the javax to jakarta namespace change, removes WebSecurityConfigurerAdapter and moves configuration to the lambda DSL. For applications with non-trivial security configuration this is often the longest single task in a Spring Boot 2 to 3 upgrade.

The newer lines have short windows too. Spring Security 6.0 to 6.5 are already past community end of life, and open source support for 7.0 ends on 31 December 2026, so even the upgraded stack needs a plan for its own date.

Auditors read this layer closely. Authentication and authorization weaknesses map directly to PCI DSS Requirement 6, the HIPAA technical safeguards in section 164.312 and SOC 2 CC6, and an unpatched auth layer is a finding in most audits.

Spring Security 5.6, 5.7 or 5.8 inside applications on Spring Framework 5.3 or Spring Boot 2.6 and 2.7, past community end of life.

The applications use some mix of form login, LDAP, OAuth 2.0 and OIDC clients, and resource servers validating tokens against a JWKS endpoint. Custom FilterChain and UserDetailsService configuration has built up over years. Some of these applications sit in PCI DSS or HIPAA scope, where the auth layer is the first component an assessor asks about.

Upgrade to Spring Security 6 or 7 with the rest of the stack. The right destination, but it requires Java 17, the jakarta namespace and a security configuration rewrite, and open source support for Spring Security 7.0 itself ends on 31 December 2026.

Buy Broadcom's commercial Spring subscription, which extends support for the Spring 5.x-era lines under a paid contract.

Mitigate in front of the application with a WAF rule or a gateway check for each new advisory. Useful as a stopgap, but it does not change what the scanner or the auditor sees in the dependency tree.

Take third-party extended support for Spring Security 5.x, patched in step with Framework 5.3 and Boot 2.7.

OSSeva patches Spring Security 5.6.x, 5.7.x and 5.8.x along with the Spring Framework 5.3 and Spring Boot 2.7 lines they are pinned to, so the auth layer is never the component left behind. Coverage spans spring-security-core, web, config, ldap, oauth2-client and oauth2-resource-server, including token validation and JWKS handling.

Any CVE that enables authentication bypass or privilege escalation is treated as P1, with immediate notification to all active customers and direct engineer escalation for Operate customers. The builds are binary-compatible with upstream 5.x, so FilterChain, UserDetailsService and OAuth2 configuration stay as they are.

OSSeva Assure includes the Spring Security 6 migration assessment: javax to jakarta impact, the extent of WebSecurityConfigurerAdapter removal, the lambda DSL migration and configuration recommendations, so the upgrade is planned from the application's actual configuration. OSSeva also patches Spring Security 6.0 to 6.5 after community end of life and covers the current 7.x lines, so the same contract follows the application through the upgrade.