Cloudanix VulnDB

CVE-2025-41232

Critical · 9.1

CVSS

9.1

EPSS

0.6%

Published

May 21, 2025

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Certain private functions that should have required login or permission checks could be reached without those checks when a specific security setting was turned on.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Privilege Gain
Component
Library
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The AspectJ-based method security interceptor fails to locate @PreAuthorize, @PostAuthorize and related annotations on private methods, allowing direct invocation without the expected authorization checks.

Why it matters to the business

Attackers can reach internal application functions that should have been protected, potentially exposing sensitive data or allowing unauthorized actions until the configuration is corrected or the library is updated.

How an attack unfolds

An attacker sends a request that targets a private method annotated with Spring Security method-security annotations while the application runs with @EnableMethodSecurity(mode=ASPECTJ) and spring-security-aspects on the classpath; because the aspect does not intercept the call, the method executes without authorization evaluation.

How to fix it

Disable AspectJ mode or move security annotations to non-private methods; if AspectJ mode must be retained, upgrade the Spring Security Aspects component to a release that correctly processes private-method annotations. For the listed Ubuntu packages the corrected versions are 1:0.5.32-1ubuntu0.1~esm1 (20.04), 1:0.5.39-1ubuntu0.1~esm1 (22.04) and 1:0.5.46-1ubuntu2+esm1 (24.04).

How to confirm the fix worked

Review the application configuration for @EnableMethodSecurity(mode=ASPECTJ), scan private methods for Spring Security annotations, and confirm that after the upgrade or configuration change the same calls are now denied when authorization should fail.

Typical attack path

  1. Discover an application that enables AspectJ method security and annotates private methods
  2. Identify the private method signatures that carry security annotations
  3. Issue a direct call or crafted request that reaches the private method entry point
  4. Observe successful execution that would normally have been denied

How to detect it

Search application logs and audit trails for successful invocations of methods that are declared private yet carry security annotations; correlate with absence of expected authorization decision log entries from Spring Security.

What your security team should do

  • Audit all codebases for @EnableMethodSecurity(mode=ASPECTJ) combined with private-method annotations
  • Apply the listed fixed package versions or refactor annotations to non-private methods
  • Add a build-time check that rejects private methods carrying method-security annotations when AspectJ mode is active
  • Monitor EPSS and any future KEV entries for this identifier given its high CVSS

The record

Spring Security Aspects may not correctly locate method security annotations on private methods. This can cause an authorization bypass. Your application may be affected by this if the following are true: * You are using @EnableMethodSecurity(mode=ASPECTJ) and spring-security-aspects, and * You have Spring Security method annotations on a private method In that case, the target method may be able to be invoked without proper authorization. You are not affected if: * You are not using @EnableMethodSecurity(mode=ASPECTJ) or spring-security-aspects, or * You have no Spring Security-annotated private methods

Affected packages

Ecosystem Package Introduced Fixed
Maven org.springframework.security:spring-security-aspects 6.4.0 6.4.6
Maven org.springframework.security:spring-security-core 6.4.0 6.4.6
maven org.springframework.security/spring-security-aspects 6.4.0 6.4.6
maven org.springframework.security/spring-security-core 6.4.0 6.4.6

Related vulnerabilities