In early 2025, a new vulnerability was assigned as CVE-2025-22235, affecting applications that rely on Spring Security to protect application endpoints. This particular weakness is subtle but significant: it arises when the EndpointRequest.to() method is used on endpoints that are *not exposed* or *are disabled* in your application. In these cases, EndpointRequest.to() inadvertently creates a matcher that matches /null (the literal string), potentially leaving application resources under-protected or even exposed.

In this post, we’ll walk through how the issue occurs, demonstrate it with code snippets, explain how it could be exploited, and lay out recommended mitigations. All information is presented in clear, simple terms without jargon, and all code is exclusive to this post.

This vulnerability can sneak into your codebase if

* You use Spring Security.
* You set up a security rule using EndpointRequest.to() in your configuration.
* The targeted endpoint is either disabled or not exposed (for example, some actuator endpoints not enabled via management.endpoints.web.exposure.include or explicitly disabled).
* Your application has a /null route, and this route should be protected.

If all four are true, your /null path may be unprotected or protected by the wrong security rule.

You are not affected if

* You do *not* use Spring Security.
* You do *not* use EndpointRequest.to() anywhere in your configs.
* The endpoint you refer to is enabled and web-exposed.
* Your app does not handle /null or that path does not require protection.

Mechanics Behind the CVE

Spring Security’s EndpointRequest matcher is often used to grant or limit access to *actuator endpoints*. Typically, it is used as:

http
    .authorizeRequests()
    .requestMatchers(EndpointRequest.to(HealthEndpoint.class)).permitAll()
    .anyRequest().authenticated();

But if for some reason the HealthEndpoint is not enabled or exposed in your config, EndpointRequest.to(HealthEndpoint.class) will — instead of matching nothing — create a matcher that matches requests to /null.

This can allow unintentional access to /null (or if you allow all actuator endpoints, it can result in an unexpected security hole).

Suppose you have the following config in your application.properties

management.endpoints.web.exposure.include=info
# Health endpoint is NOT included, so it's not exposed

And a security config like this

import org.springframework.boot.actuate.health.HealthEndpoint;
import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                // Supposed to allow health endpoint for anyone
                .requestMatchers(EndpointRequest.to(HealthEndpoint.class)).permitAll()
                .anyRequest().authenticated()
            .and()
            .httpBasic();
    }
}

Now, because the HealthEndpoint isn’t exposed, EndpointRequest.to(HealthEndpoint.class) becomes a matcher for the /null route.

That means this endpoint

GET /null

...will be matched by the rule above. If your code has anything mapped to /null (maybe by accident or for another use), the security rule meant for /actuator/health will now apply. Worse, attackers can brute-force or guess this pattern, and discover /null is permitted for all (or subject to the wrong authorization).

Let’s say your app does have a controller like this (maybe for testing)

@RestController
public class ExampleController {
    @GetMapping("/null")
    public String nullHandler() {
        return "This is the /null endpoint";
    }
}

With the misconfigured security, anyone can now access /null with no authentication required

curl http://localhost:808/null

And would see

This is the /null endpoint

This is potentially dangerous if /null is an internal or sensitive route, or simply unexpected.

Why is This Dangerous?

- Unexpected exposure: You intended to expose an actuator endpoint, but exposed a different URI (/null).
- Security bypass: All security configured for the actual endpoint is now (mis)applied to /null.
- Brute-force risk: Attackers can easily try /null on various Spring Boot applications.
- Chaining with other bugs: /null access could let attackers probe other internal logic or framework components.

References

- Spring Security Docs - EndpointRequest
- Spring Boot Actuator Endpoints
- NVD Entry for CVE-2025-22235 (if/when published)

* Don’t include unnecessary endpoints in management.endpoints.web.exposure.include.

3. Never use /null for your routes:

Explicit matchers:

* If you need to expose only actuator endpoints, consider using explicit antMatchers with known URIs.

Summary

CVE-2025-22235 might sound like a niche issue, but it’s easy to trip over—just one misconfigured actuator endpoint and an overlooked usage of EndpointRequest.to() can open a backdoor on the /null route. The best fix is to keep your configuration tight and your dependencies up to date.

If your team uses Spring Security and actuator endpoints, audit your configs today!


For updates and more examples, watch the official Spring Security repository.

Timeline

Published on: 04/28/2025 08:15:15 UTC
Last modified on: 04/29/2025 13:52:10 UTC