CVE-2024-22234: Spring Security Auth Bypass Vulnerability

CVE-2024-22234 Overview

CVE-2024-22234 is a broken access control vulnerability in Spring Security affecting versions 6.1.x prior to 6.1.7 and 6.2.x prior to 6.2.2. The flaw exists in the AuthenticationTrustResolver.isFullyAuthenticated(Authentication) method. When an application passes a null authentication parameter to this method, it incorrectly returns true, indicating the request is fully authenticated. Applications that call this method directly with untrusted or unchecked authentication objects can bypass authorization checks. The vulnerability is categorized under [CWE-284] Improper Access Control.

Critical Impact
Applications directly invoking isFullyAuthenticated with a null argument treat unauthenticated requests as fully authenticated, exposing protected functionality to unauthorized users.

Affected Products

Spring Security 6.1.x versions prior to 6.1.7
Spring Security 6.2.x versions prior to 6.2.2
NetApp products bundling affected Spring Security releases (see NetApp advisory NTAP-20240315-0003)

Discovery Timeline

2024-02-20 - CVE-2024-22234 published to NVD
2024-03-15 - NetApp publishes advisory NTAP-20240315-0003 for downstream impact
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-22234

Vulnerability Analysis

Spring Security provides AuthenticationTrustResolver as a helper to distinguish between anonymous, remember-me, and fully authenticated principals. The isFullyAuthenticated(Authentication) method is meant to return true only when a concrete, non-anonymous Authentication object is present. In the affected versions, the implementation does not correctly handle a null input. Instead of returning false or throwing an exception, the method returns true for null. Any authorization branch that treats a true result as evidence of a real, logged-in user will then permit access to protected resources.

The issue manifests only when developers use the resolver directly in custom code. Applications that rely on Spring Security's declarative Method Security or HTTP request authorization DSLs are not affected, because those code paths do not pass null values into the resolver.

Root Cause

The root cause is missing null-input validation inside AuthenticationTrustResolver.isFullyAuthenticated. The method's boolean logic evaluates negatively-scoped checks (for example, verifying the token is not anonymous and not remember-me) against a null reference, which short-circuits to a true result. The design assumed callers would supply a non-null Authentication, but the public API contract did not enforce that assumption.

Attack Vector

An attacker submits a request that produces a nullAuthentication in the security context, for example by targeting an endpoint that is not covered by the authentication filter chain or by manipulating the request so no principal is resolved. When custom authorization logic calls trustResolver.isFullyAuthenticated(auth) with that null value, the check returns true and the attacker gains access reserved for authenticated users. Exploitation requires that vulnerable code exist in the application and that an attacker can trigger the code path with a null authentication. This raises attack complexity but does not require credentials or user interaction.

No verified public proof-of-concept code exists for this issue. Refer to the Spring Security CVE-2024-22234 advisory for the vendor's technical description and patch commits.

Detection Methods for CVE-2024-22234

Indicators of Compromise

Application logs showing successful access to authenticated-only endpoints without a preceding authentication event or session identifier
Audit trails where privileged actions are attributed to an empty or missing principal
Repeated requests to protected URLs from anonymous clients that receive HTTP 200 responses instead of 401 or 403

Detection Strategies

Perform static analysis to identify direct callers of AuthenticationTrustResolver.isFullyAuthenticated and inspect whether null inputs are possible
Add unit and integration tests that pass null to any custom trust-resolver call sites and assert access is denied
Review dependency manifests (pom.xml, build.gradle) for spring-security-core versions below 6.1.7 or 6.2.2

Monitoring Recommendations

Alert on authorization decisions granted to sessions with no associated authenticated principal
Track version inventory for Spring Security across all Java services and flag builds pinned to vulnerable ranges
Correlate WAF access logs with application-level audit events to spot unauthenticated traffic reaching protected controllers

How to Mitigate CVE-2024-22234

Immediate Actions Required

Upgrade Spring Security to 6.1.7 or 6.2.2 or later on all affected services
Audit application source code for direct usage of AuthenticationTrustResolver.isFullyAuthenticated(Authentication) and validate inputs
Rebuild and redeploy any dependent artifacts, including containers and internal libraries, that bundle the older Spring Security jars

Patch Information

Pivotal released fixed versions Spring Security 6.1.7 and 6.2.2 addressing the null-handling defect in AuthenticationTrustResolver. Downstream NetApp products should follow guidance in NetApp Security Advisory NTAP-20240315-0003. Full remediation details are in the Spring Security advisory.

Workarounds

Wrap direct calls with an explicit null check: return false when the Authentication argument is null before delegating to the resolver
Refactor custom authorization code to use Spring Security Method Security annotations or the HTTP request authorization DSL, which are not affected
Ensure the security filter chain populates a non-null Authentication (for example, an AnonymousAuthenticationToken) for every request path

bash

# Maven dependency upgrade example
mvn versions:use-dep-version \
  -Dincludes=org.springframework.security:spring-security-core \
  -DdepVersion=6.2.2 -DforceVersion=true

# Gradle equivalent
# implementation 'org.springframework.security:spring-security-core:6.2.2'