CVE-2024-22234

What it actually does

Spring Security 6.1.x before 6.1.7 and 6.2.x before 6.2.2 can incorrectly treat a null Authentication object as fully authenticated when application code directly calls AuthenticationTrustResolver.isFullyAuthenticated(Authentication). If custom authorization logic relies on that direct method call and can pass null into it, unauthenticated requests may satisfy checks intended only for fully authenticated users. The impact is broken access control with potential unauthorized access to protected functions or data. Applications using Spring Method Security or HTTP Request Security abstractions for isFullyAuthenticated, or applications that never pass null to the method, are not affected by the vulnerable condition.

Why it matters to the business

The primary business risk is that an unauthenticated user may be able to access application functionality or sensitive data that should require login, depending on how the application implemented custom authorization checks. This can lead to confidentiality and integrity impacts such as unauthorized viewing, modification, or workflow abuse. Exploitation requires a specific coding pattern, so broad commodity exploitation is less likely than for a default-exposed remote code execution issue; EPSS is low and the issue is not listed in CISA KEV. However, Spring Security is widely used in enterprise Java applications, so organizations should prioritize review and upgrade for applications with custom authorization logic using this API.

How an attack unfolds

An attacker first identifies a Spring-based application endpoint or workflow protected by custom authorization logic rather than standard Spring Method Security or HTTP Request Security. The attacker then sends requests without valid authentication, or in a state that causes the application to pass a null Authentication object into AuthenticationTrustResolver.isFullyAuthenticated(Authentication). In vulnerable Spring Security versions, that null input can produce an erroneous true result. If the application trusts that result to authorize access, the attacker is treated as fully authenticated for that code path and can reach protected data or actions without valid credentials. The attacker’s practical impact depends entirely on what the affected custom check gates, such as administrative functions, user data access, account actions, or internal business workflows.

How to fix it

Upgrade Spring Security to a fixed release: use 6.1.7 or later for the 6.1.x line, or 6.2.2 or later for the 6.2.x line. If consuming source directly, ensure the fix including commit dd5bfc0b3126a33c574354adf8d71fd4b34175ba is present. Review dependency management files and transitive dependency resolution to confirm the runtime artifact is not an affected version. As a code-level mitigation, avoid direct use of AuthenticationTrustResolver.isFullyAuthenticated(Authentication) in custom authorization logic, explicitly handle null Authentication as unauthenticated, and prefer Spring Security’s built-in Method Security and HTTP Request Security authorization mechanisms where possible. Add defensive tests that verify anonymous, missing, expired, and invalid authentication states are denied for protected endpoints.

How to confirm the fix worked

Confirm the application resolves Spring Security to version 6.1.7 or later, 6.2.2 or later, or another vendor-provided fixed build. Validate with dependency tooling such as Maven dependency:tree, Gradle dependencies, software composition analysis, or runtime package inspection. Search application source for direct calls to AuthenticationTrustResolver.isFullyAuthenticated and verify null inputs are impossible or explicitly denied. Run negative authorization tests against protected endpoints with no session, no token, invalid token, expired token, and anonymous authentication; all protected actions should return an authorization failure rather than success. If the source build is used, confirm the repository contains the fix commit dd5bfc0b3126a33c574354adf8d71fd4b34175ba or equivalent patched logic.

Typical attack path

1. Reconnaissance identifies a Spring Security application and candidate endpoints with custom authentication or authorization behavior.
2. The attacker tests unauthenticated or session-less requests against protected workflows to find inconsistent authorization responses.
3. A vulnerable code path passes a null Authentication object into AuthenticationTrustResolver.isFullyAuthenticated(Authentication).
4. The vulnerable Spring Security version incorrectly returns true for the null authentication case.
5. Application-specific authorization logic grants access because it interprets the result as proof of full authentication.
6. The attacker accesses or modifies protected resources available behind that flawed authorization check.

How to detect it

There are no universal network signatures, exploit strings, file artifacts, or process indicators for this issue because exploitation is application-logic-specific and leaves the same kinds of traces as normal web requests. To assess possible prior exploitation, review application access logs, authentication logs, authorization decision logs, API gateway logs, reverse proxy logs, and audit trails for protected endpoints returning successful responses when no authenticated principal, session, bearer token, or security context was present. Focus on endpoints guarded by custom code that directly uses AuthenticationTrustResolver.isFullyAuthenticated(Authentication). Look for sequences where unauthenticated clients receive HTTP 200, 201, 204, or business-success responses for actions that should require login, especially administrative, account-management, data export, update, or workflow approval operations. If debug or application logs include security context information, search for null Authentication, missing principal, anonymous authentication transitions, or authorization success records with an absent user identity. Correlate suspicious successful unauthenticated requests with downstream data access, object changes, privilege-sensitive operations, and unusual source IPs or user agents. Absence of these artifacts does not prove non-exploitation unless the application logs authorization context and protected action outcomes with sufficient detail.

What your security team should do

• Inventory Java applications using Spring Security 6.1.x or 6.2.x and prioritize internet-facing, high-value, and administrative applications.
• Upgrade affected applications to Spring Security 6.1.7+, 6.2.2+, or a later supported release line as soon as practical.
• Search codebases for direct calls to AuthenticationTrustResolver.isFullyAuthenticated(Authentication) and require explicit null handling before authorization decisions are made.
• Prioritize testing for applications with custom authorization wrappers, custom filters, custom access decision logic, or non-standard session/token handling.
• Add regression tests that confirm unauthenticated requests cannot access protected endpoints when Authentication is null.
• Review access logs for historical unauthenticated success responses to sensitive routes, especially after the vulnerability publication date of 2024-02-20.
• Because this is not in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, handle as targeted remediation rather than emergency internet-wide incident response unless vulnerable custom code is confirmed.