spring-security-core Maven: Keeping Your Auth Layer Patched

The spring-security-core Maven artifact governs authentication and authorization for most Spring applications, which makes an outdated version one of the highest-leverage risks in a Java stack. A bypass here does not leak a config value or slow a request — it lets someone reach endpoints they were never authorized to touch. Several 2024 and 2025 CVEs land squarely in that category, so treating the version as "set once and forget" is a mistake.

This guide covers how the Spring Security modules fit together, the advisories worth knowing, and how to keep the whole family patched through Maven.

The module family, briefly

Spring Security is not one JAR. When you add starters or explicit dependencies, you pull several coordinated artifacts, all versioned together:

<dependency>
  <groupId>org.springframework.security</groupId>
  <artifactId>spring-security-core</artifactId>
  <version>6.5.4</version>
</dependency>

The related coordinates you will commonly see are spring-security-web maven (servlet filter chain and HTTP-layer security), spring-security-config maven (the Java DSL and namespace configuration), and spring-security-crypto maven (password encoders, key generators). If you do OAuth, you will also pull spring-security-oauth2-client maven for acting as a client and the broader spring-security-oauth2 maven modules for resource-server and JOSE support. The critical rule: keep every one of these on the same version. Mixing a patched spring-security-core with an older spring-security-web produces classpath conflicts and, worse, silent gaps.

CVE-2024-22257: erroneous authentication pass

CVE-2024-22257 is a broken access control issue in applications that directly call AuthenticatedVoter#vote with a null Authentication parameter. Affected ranges include 5.7.x before 5.7.12, 5.8.x before 5.8.11, 6.0.x before 6.0.9, 6.1.x before 6.1.8, and 6.2.x before 6.2.3. Most apps that stick to the standard DSL are not directly exposed, but any custom voter code should be reviewed and the dependency bumped regardless.

CVE-2024-38827: locale-dependent authorization

CVE-2024-38827 is subtler and, in a way, more instructive. Authorization rules that compared strings could behave incorrectly under certain locales — the classic Turkish-locale case sensitivity trap where "ADMIN".toLowerCase() does not produce what you expect. The result is authorization rules failing to match as intended. Fixed versions span the 5.7 through 6.3 lines; consult the advisory for the exact patched build in your branch. The lesson generalizes: never build authorization comparisons on locale-sensitive string operations in your own code either.

CVE-2025-41248: method security bypass on parameterized types

The one to pay closest attention to in recent releases is CVE-2025-41248. Method-security annotations such as @PreAuthorize and @PostAuthorize could be skipped entirely when applied to methods in generic superclasses or interfaces with parameterized type arguments. In practice, an annotation you believed was guarding a method silently did nothing. It affects Spring Security 6.4.0 through 6.4.9 and 6.5.0 through 6.5.3, and a companion issue in Spring Framework, CVE-2025-41249, tracks the annotation-detection side.

If you use generic service or repository base classes — a very common Spring pattern — and secure their methods with annotations, this affects you. Upgrade to 6.4.10 / 6.5.4 or later.

Managing the version through Maven

The clean way to keep the whole family aligned is a BOM. If you use spring-boot-starter-parent, Boot already manages the Spring Security version for you, and upgrading Boot upgrades Security. When you manage it independently, import the BOM:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.security</groupId>
      <artifactId>spring-security-bom</artifactId>
      <version>6.5.4</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With the BOM imported, you omit the <version> on individual artifacts and they all resolve to a single, coordinated release. That eliminates the mixed-version footgun entirely.

To see what you are actually resolving — including transitive Spring Security brought in by other libraries — run:

mvn dependency:tree -Dincludes=org.springframework.security

This is where surprises live. A third-party integration library can drag in an old spring-security-core that overrides your intended version through Maven's nearest-wins resolution. Continuous software composition analysis flags these transitively rather than trusting the version you declared in the top-level POM.

A patching workflow that holds up

• Pin the Spring Security (or Spring Boot) version explicitly and drive it through the BOM.
• Wire Dependabot or Renovate to open PRs on new Spring Security releases; these ship on a predictable cadence.
• Run mvn dependency:tree in CI and fail the build if a Spring Security version other than the managed one resolves.
• Audit any custom voters, AccessDecisionManager implementations, or annotated methods on generic base classes against the CVEs above.
• Treat authorization test coverage as a first-class requirement — a bypass CVE is only dangerous if nothing catches the regression.

If you are weighing scanners for Java dependency risk, our comparison with Snyk and the Safeguard Academy both go deeper on Maven resolution mechanics.

FAQ

Which Spring Security modules do I actually need?

At minimum, spring-security-core plus spring-security-config and, for web apps, spring-security-web. Add spring-security-crypto if you use its encoders directly and the spring-security-oauth2-* modules only if you implement OAuth2 client or resource-server flows. Keep all of them on one version.

Do I need to worry about these CVEs if I use Spring Boot?

Yes — Spring Boot manages the Spring Security version, so an outdated Boot version pins outdated Security. Upgrading Boot is the usual fix, and Boot's release notes reference the Security version it brings.

How do I check my current spring-security-core version?

Run mvn dependency:tree -Dincludes=org.springframework.security. It shows the resolved version and reveals any transitive copies pulled in by other dependencies that may override your intended version.

Is CVE-2025-41248 relevant if I only use URL-based security?

It specifically affects method security annotations (@PreAuthorize, @PostAuthorize) on parameterized generic types. Purely URL/filter-based authorization is not the target, but most non-trivial apps mix both, so upgrading is the safe call.