A critical vulnerability was assigned as CVE-2025-41232, affecting Java applications using Spring Security's method-level security in a particular configuration. In this post, we’ll break down what this bug is, which setups are susceptible, show example exploit code, and provide links for further reading. We'll use simple terms without skipping important technical details, so any developer can judge if they are affected.

What’s the Problem?

Spring Security provides a way to secure methods using annotations like @PreAuthorize, @Secured, and more. Normally, adding these to sensitive methods prevents unauthorized access. But, if you’re using AspectJ-based method security on private methods, there’s a flaw:

> Spring Security Aspects may not correctly locate method security annotations on private methods.

In plain English:
Anyone might be able to call your sensitive, "private" methods and bypass your security checks. This is not the case for public or protected methods, just private ones.

You are at risk if

- You use @EnableMethodSecurity(mode=ASPECTJ) and include spring-security-aspects in your project.

You do not use spring-security-aspects at all.

If this sounds like your project, don’t panic: keep reading!

Why Does This Happen?

AspectJ weaves in security checks at the bytecode level. If it fails to recognize the annotation (because it's on a private method), the security check is skipped. That means the method could be invoked internally (and sometimes externally, through tricks) without Spring blocking unauthorized users—even when you think it's protected.

Let's look at a vulnerable example

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.stereotype.Service;

@Service
public class BankService {

    // This should only be called by ADMIN users
    @PreAuthorize("hasRole('ADMIN')")
    private void transferFunds() {
        System.out.println("Transferring funds!");
    }

    // Called by anyone
    public void publicApi() {
        // invoke private method
        transferFunds();
    }
}

You set up Spring Security with

@EnableMethodSecurity(mode = AdviceMode.ASPECTJ)

What You Expect

Only ADMIN users can trigger transferFunds(), right? If an attacker has access to anything calling publicApi(), they’ll be blocked. WRONG!

What Actually Happens

Due to CVE-2025-41232, AspectJ doesn't enforce the @PreAuthorize check on private methods. Any code, even code running as an unauthorized user, can call publicApi() and, internally, the transferFunds() will run without any security check.

Assume a web controller like

@RestController
@RequestMapping("/api")
public class BankController {
    @Autowired
    private BankService bankService;

    @PostMapping("/transfer")
    public ResponseEntity<?> triggerTransfer() {
        bankService.publicApi(); // No security check!
        return ResponseEntity.ok("Triggered transfer");
    }
}

Any user—even without ADMIN rights—can POST to /api/transfer, and funds get transferred.

Real World Impact

- If you trusted @PreAuthorize on private methods and rely on ASPECTJ mode, your security is broken.
- Attackers who can trigger code paths that use these private, security-annotated methods can do anything those methods allow.

`java

@EnableMethodSecurity // Don't set mode=ASPECTJ!

`

Long-term:

Wait for Spring Security to release a patch. Track the issue at

- Spring Security CVE-2025-41232 Announcement
- Spring Security GitHub Issue (if available) *(search for 41232)*

Spring Security Docs:

https://docs.spring.io/spring-security/reference/servlet/authorization/method-security.html

Original Announcement:

Spring CVE-2025-41232 Advisory

Spring Security Aspects:

https://mvnrepository.com/artifact/org.springframework.security/spring-security-aspects

Bottom Line

If you use Spring Security’s AspectJ mode and security-annotate private methods, your code is at risk of authorization bypass!
Check your configs and code, and move all @PreAuthorize (and similar) annotations away from private methods. Stick to public/protected, or switch back to proxy mode until a patch is available.

Stay safe, and keep your code locked down!

*Did this help your understanding? Bookmark for speedy incident response!*

Timeline

Published on: 05/21/2025 12:16:21 UTC
Last modified on: 05/21/2025 20:24:58 UTC