CVE-2025-22235

What it actually does

This is an authorization bypass condition in applications using Spring Security actuator endpoint matchers. When `EndpointRequest.to()` is configured for an actuator endpoint that is disabled or not exposed over the web, the generated security matcher can incorrectly target `null/**`. If the application also serves sensitive functionality under `/null`, the intended Spring Security authorization rules may be applied to the wrong path or may unintentionally expose that route, allowing unauthenticated network users to access functionality that was expected to require authorization. The reported impact is limited confidentiality, integrity, and availability impact, but severity depends heavily on what the application exposes beneath `/null`. The affected Red Hat Ansible Automation Platform 2.4 packages listed for this advisory are `receptor` and `receptorctl` on el8 and el9 streams.

Why it matters to the business

If an affected application exposes protected operations or data under `/null`, users who should not have access may be able to view information, trigger actions, or interfere with application behavior. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no listed public exploit maturity, so broad active exploitation is not indicated from the supplied data. However, because the flaw is remotely reachable and requires no authentication when the vulnerable routing and security configuration are present, externally exposed applications that handle `/null` should still be reviewed and patched. Organizations using the affected Red Hat Ansible Automation Platform 2.4 `receptor` or `receptorctl` packages should upgrade to the fixed package builds to reduce exposure and maintain vendor supportability.

How an attack unfolds

An attacker first identifies an application using Spring Security actuator endpoint security configuration and probes for routes under `/null`. The vulnerability only becomes exploitable when `EndpointRequest.to()` references an actuator endpoint that is disabled or not exposed, causing a matcher for `null/**`, and the application separately handles `/null` or `/null/...` paths that require protection. The attacker sends unauthenticated HTTP requests to those `/null` paths and observes whether access is granted without the expected login, token, or role check. If sensitive handlers exist below that path, the attacker can read exposed data, invoke state-changing actions, or disrupt behavior according to the permissions unintentionally granted by the misapplied matcher. There are no named threat actors or known exploitation campaigns provided for this issue.

How to fix it

Upgrade affected vendor packages to fixed versions. For Red Hat Ansible Automation Platform 2.4 on el8, update `receptor` and `receptorctl` to `0:1.4.2-1.el8ap` or later. For Red Hat Ansible Automation Platform 2.4 on el9, update `receptor` and `receptorctl` to `0:1.4.2-1.el9ap` or later. For Spring applications, also review Spring Security configuration for any use of `EndpointRequest.to()` that references disabled or non-web-exposed actuator endpoints. Ensure referenced actuator endpoints are enabled and exposed if they are used in security matchers, or replace the matcher with explicit, validated request matchers. If the application handles `/null` or `/null/**`, require explicit authentication and authorization on those routes or remove the route if it is unintended. As a temporary mitigation, block external access to `/null` and `/null/**` at a reverse proxy, ingress controller, WAF, or API gateway, and add deny-by-default rules for unexpected routes.

How to confirm the fix worked

Confirm package remediation by checking installed package versions and verifying `receptor` and `receptorctl` are at least `0:1.4.2-1.el8ap` on el8 systems or `0:1.4.2-1.el9ap` on el9 systems. For application-level validation, inspect Spring Security configuration for `EndpointRequest.to()` usage and verify the referenced actuator endpoint is enabled and exposed over web, or that the matcher has been replaced with an explicit safe matcher. Test unauthenticated requests to `/null` and representative `/null/**` paths in a non-production-safe manner; protected routes should return an authentication challenge, authorization denial, or not-found response as appropriate, and must not expose sensitive functionality. Validate effective security behavior with integration tests that assert expected authorization outcomes for `/null`, `/null/`, and nested paths.

Typical attack path

1. Discover an internet-facing or reachable Java/Spring-based application or service.
2. Probe common and application-specific paths under `/null` and `/null/` using unauthenticated HTTP requests.
3. Identify responses that return application functionality, data, or state-changing behavior without the expected authentication challenge or authorization failure.
4. Interact with exposed `/null/**` endpoints to access protected information or invoke unintended operations.
5. Use any returned data or application behavior to support further reconnaissance, lateral movement, or operational disruption, depending on what the exposed route provides.

How to detect it

Review HTTP access logs from web servers, reverse proxies, load balancers, API gateways, WAFs, and application servers for requests to `/null`, `/null/`, or `/null/...`, especially responses with HTTP 200, 201, 202, 204, 3xx, or application-specific success codes where the request lacked a valid authenticated user or session. Compare these events against authentication logs to identify successful access without a corresponding login, token validation, or authorized principal. Look for scanning patterns such as repeated probes of `/null`, URL-encoded variants, and nested paths from the same source IP. In application logs, search for handlers, controller methods, or security filter decisions involving `null/**` or `EndpointRequest.to()` behavior. For forensic review, identify whether any state-changing HTTP methods such as POST, PUT, PATCH, or DELETE were accepted under `/null/**`. Because exploitation depends on application-specific routes, the strongest evidence is a successful unauthenticated request to a sensitive `/null/**` endpoint, not merely a 404 probe.

• GET /null
• GET /null/
• POST /null
• POST /null/
• PUT /null
• PUT /null/
• PATCH /null
• PATCH /null/
• DELETE /null
• DELETE /null/
• /null/
• null/**
• EndpointRequest.to(

What your security team should do

• Inventory applications and packaged deployments that use Spring Security actuator endpoint authorization, especially configurations containing `EndpointRequest.to()`.
• Prioritize review of externally reachable services and any application that defines handlers, controllers, routes, or reverse-proxy mappings under `/null` or `/null/**`.
• Patch affected Red Hat Ansible Automation Platform 2.4 `receptor` and `receptorctl` packages to `0:1.4.2-1.el8ap` or `0:1.4.2-1.el9ap` as appropriate.
• Add temporary WAF, ingress, or reverse-proxy controls to deny unauthenticated access to `/null` and `/null/**` where those paths are not explicitly required.
• Create regression tests for Spring Security configuration to ensure disabled or non-exposed actuator endpoints do not create unintended request matchers.
• Search historical web, gateway, and application logs for unexpected successful requests to `/null` or `/null/**`, especially from unauthenticated clients.
• Treat confirmed unauthenticated access to sensitive `/null/**` functionality as a security incident and scope data exposure or unauthorized actions performed through those routes.