CVE-2024-22257

What it actually does

This is a broken access control flaw in Spring Security where applications that directly call `AuthenticatedVoter#vote` with a `null` `Authentication` object can receive an incorrect authorization decision. In affected Spring Security versions, that misuse can allow logic intended for authenticated users to be evaluated incorrectly, potentially granting access to protected functionality or data without a valid authenticated principal. The issue is application-pattern dependent: applications using normal Spring Security authorization flows are less likely to be affected than applications that manually invoke `AuthenticatedVoter#vote` or wrap it in custom authorization logic.

Why it matters to the business

Successful exploitation can allow unauthenticated or improperly authenticated users to access application functions or sensitive information that should require login or stronger authorization. Because this affects a widely used security framework, organizations should prioritize inventorying custom Spring Security authorization code even though the CVE is not in CISA KEV, has no known ransomware association, and currently has low EPSS probability and no public exploit maturity reported. The provided package metadata also references AlmaLinux 8 `ibus` packages fixed in `1.5.19-13.el8`; validate whether those packages are actually relevant to this CVE in local advisory tooling, because the vulnerability description itself is for Spring Security.

How an attack unfolds

An attacker first identifies an application built with an affected Spring Security version and looks for protected routes or API operations whose authorization checks rely on custom code rather than the standard framework filter chain. If the application directly invokes `AuthenticatedVoter#vote` and can reach that code path with a missing or null authentication context, the attacker sends requests that avoid establishing a valid authenticated session while still triggering the custom authorization decision. The flawed voter behavior may cause the application to treat the request as authorized, allowing access to data or operations intended only for authenticated users. Exploitation depends on application-specific implementation details; there is no universal exploit payload for all Spring Security deployments.

How to fix it

Upgrade Spring Security to a fixed release: 5.7.x users should upgrade to 5.7.12 or later; 5.8.x to 5.8.11 or later; 6.0.x to 6.0.9 or later; 6.1.x to 6.1.8 or later; and 6.2.x to 6.2.3 or later. Review custom authorization code and remove direct calls to `AuthenticatedVoter#vote` where possible; prefer the supported Spring Security authorization mechanisms and ensure any authorization decision explicitly denies access when `Authentication` is null. Add defensive checks that fail closed for missing, anonymous, expired, or invalid authentication contexts. If the AlmaLinux 8 package advisories in the supplied metadata are applicable to the asset inventory, update `ibus`, `ibus-devel`, `ibus-devel-docs`, `ibus-gtk2`, `ibus-gtk3`, `ibus-libs`, `ibus-setup`, and `ibus-wayland` to `1.5.19-13.el8` or later, but verify the advisory mapping because those packages do not align with the Spring Security vulnerability description.

How to confirm the fix worked

Confirm dependency versions through build manifests and runtime inventory, including Maven or Gradle dependency trees, SBOMs, container images, and deployed application artifacts. Verify that `spring-security-*` modules are at or above the fixed versions for the relevant release line. Search application source code for direct usage of `AuthenticatedVoter`, especially calls to `AuthenticatedVoter#vote` or `.vote(` where the `Authentication` argument may be null. Add or run authorization tests that submit requests with no session, no bearer token, expired credentials, malformed credentials, and anonymous authentication, and confirm protected operations are denied. For package-based validation where applicable, confirm AlmaLinux 8 packages report version `1.5.19-13.el8` or later using package management tooling.

Typical attack path

1. Identify a web application or API using an affected Spring Security release.
2. Probe unauthenticated and partially authenticated endpoints for inconsistent access-control behavior.
3. Find a route or operation implemented with custom authorization logic that directly uses `AuthenticatedVoter#vote`.
4. Send requests without a valid authentication context, expired session, missing token, or malformed authorization state to trigger a null `Authentication` path.
5. Observe whether protected content, privileged API responses, or state-changing actions are allowed despite the missing authenticated principal.
6. Use the unauthorized access to read sensitive data or perform actions normally limited to authenticated users.

How to detect it

There are no reliable universal indicators of compromise for this issue because exploitation depends on application-specific authorization code and may look like ordinary HTTP requests. Review application, API gateway, WAF, identity provider, and access logs for successful requests to protected endpoints where the user identity is missing, anonymous, null, expired, or otherwise not associated with a valid authenticated session. Look for HTTP 200, 201, 204, or other successful responses on URLs that should require authentication, especially following requests with absent `Authorization` headers, invalid bearer tokens, expired sessions, missing cookies, or logout events. Correlate privileged actions with authentication events to identify operations that occurred without a preceding successful login or token validation. In source and build artifacts, search for direct `AuthenticatedVoter` usage and then examine historical logs for unauthenticated successful access to the associated routes. If enhanced application logging is available, review authorization-decision logs for null `Authentication` objects, anonymous principals, or voter decisions that granted access unexpectedly.

What your security team should do

• Prioritize applications that use Spring Security and expose internet-facing login-protected APIs or administrative functions.
• Inventory Spring Security versions across source repositories, build artifacts, containers, and production deployments; upgrade affected release lines to the fixed versions.
• Perform targeted code review for custom access-control implementations and direct `AuthenticatedVoter#vote` usage.
• Add negative authorization tests that verify requests with null, missing, expired, or anonymous authentication are denied by default.
• Monitor access logs for unauthenticated requests returning successful responses from endpoints that normally require authentication.
• Validate advisory mappings in vulnerability scanners, because the supplied affected product list references AlmaLinux `ibus` packages while the vulnerability description is for Spring Security.
• Do not treat the low EPSS and absence from KEV as a reason to defer indefinitely; broken access control flaws can be high-impact when the vulnerable code pattern exists.