CVE-2025-41243: Why "Property Modification" Undersells the Blast Radius

Author: Feng Ning, Innora Security Research Published: June 3, 2026 Contact: [email protected] Reading Time: ~8 minutes

TL;DR

CVE-2025-41243 is a CVSS 10.0 bug in Spring Cloud Gateway with a title that sounds almost dull: "Spring Expression Language property modification." That label undersells it. The flaw only fires when the gateway actuator is exposed without authentication, but once that precondition holds, the same surface hands an attacker arbitrary file read (demonstrated in public analysis) and unauthenticated SSRF straight into cloud instance metadata. From there it is a short hop to IAM credentials and account takeover. This post is about that gap between the official wording and the real risk, written so defenders fix the right thing. It contains no payloads or reproduction steps; everything here is already public.

Background: the gateway actuator surface

Spring Cloud Gateway (SCG) ships a management actuator at /actuator/gateway that lets operators inspect and change routing at runtime. By default it stays closed. Exposing it is an explicit opt-in:

management.endpoints.web.exposure.include: gateway

Add that line, leave the actuator without an auth layer (no Spring Security, no upstream policy, no network restriction), and the gateway's full routing and SpEL machinery becomes reachable by anyone who can hit the management port.

The CVE was published on 2025-09-08 by the researcher Ezzer17, rated CVSS 10.0 (Critical). NVD assigns two weakness classes, CWE-94 (Code Injection) and CWE-917 (Expression Language Injection). The official advisory lists the affected ranges as 3.1.0–3.1.x, 4.0.0–4.0.x, 4.1.0–4.1.x, 4.2.0–4.2.x, and 4.3.0–4.3.x. Fixes shipped in 4.3.1 and 4.2.5 (OSS) and 4.1.11 and 3.1.11 (Enterprise); 4.0.x users have to move onto a fixed branch. Public PoCs already exist.

The gap: what "property modification" means versus what it enables

Start with the formal primitive. The CVE is SpEL injection evaluated inside a SimpleEvaluationContext sandbox. That sandbox is deliberately strict: no type references via T(...), no constructors with new, no arbitrary method calls. What is left is a property read/write primitive, not a direct call to Runtime.exec(). As a description of the SpEL channel in isolation, that is accurate. As a measure of risk to a cloud-hosted gateway, it misses most of the picture.

Property write turns into arbitrary file read. Public patch analysis by psytester shows the property-write primitive can re-point a static resource handler at the filesystem root, which converts it into arbitrary file read. Pulling /etc/passwd back through the gateway is the obvious demonstration. The same write-up walks through enumerating Spring beans and environment variables. So before any network pivot, "property modification" already gets you local file disclosure plus broad information disclosure. That author could not get RCE either, and openly questions the 10.0 score. We share the doubt. A clean CVSS 10.0 reads as "no preconditions," yet this bug needs the actuator deliberately exposed and left unauthenticated. That looks a lot closer to a high-complexity precondition than a no-barrier one, which is the part of the score worth arguing about.

The same exposure is an SSRF primitive. The actuator this CVE targets also drives route management, meaning the rules that decide where the gateway forwards traffic. SCG forwards to whatever URI a route names, and the outbound NettyRoutingFilter does not screen those URIs. There is no block on link-local addresses (the 169.254.0.0/16 range that cloud IMDS lives on), none on RFC 1918 ranges, none on loopback, and no host allowlist. The filter also streams the upstream response body back to the caller. Put those together and an unauthenticated client who reaches an exposed actuator can make the gateway fetch an internal URI and read the answer.

None of this SSRF behavior is new. It belongs to the same family as CVE-2022-22947, and the "bring your own SSRF via the gateway actuator" pattern has been written up publicly since 2021. The point worth making here is narrower: the single precondition that activates CVE-2025-41243, an exposed and unauthenticated actuator, also exposes file read, information disclosure, and cloud-metadata SSRF at the same time. "Property modification" does not say any of that.

If you take one thing away, make it this: the exposed actuator is the entry point, not the CVE. Harden the actuator and you close the file read, the information disclosure, and the SSRF in one move. This vulnerability is one more reason to do that, not the only one.

From SSRF to cloud account takeover

Cloud instance metadata services sit on a link-local address on purpose. The assumption is that anything running on the instance is trusted, so the metadata endpoint trusts it back. SSRF from inside that network namespace breaks the assumption cleanly:

1. SSRF reaches IMDS. The request is proxied through the gateway to the metadata endpoint. Nothing more than network access to the actuator is needed.
2. Credentials come back. IMDS returns the instance's attached role credentials in the response body: AWS under /latest/meta-data/iam/security-credentials/, GCP service-account tokens, Azure managed-identity tokens.
3. The blast spreads. Those short-lived credentials carry whatever the instance role allows. That can mean reading object storage and secrets managers, listing resources, or pivoting into a more privileged role. Where the role is generous, this is full account takeover.

That chain is the real risk of CVE-2025-41243 on a cloud-hosted gateway, and it is the part the official title leaves out.

What to actually do

The root cause is one configuration decision: never expose the gateway actuator to untrusted networks without authentication. Everything below follows from getting that right.

1. Patch. Move to OSS 4.3.1 or 4.2.5, or Enterprise 4.1.11 or 3.1.11. If you are on 4.0.x, jump to a fixed branch. This closes the SpEL path itself.
2. Shut or guard the actuator. If the gateway management actuator does not need to be public, take gateway out of management.endpoints.web.exposure.include. If operations need it, put /actuator/** behind Spring Security and bind it to an internal-only management port.
3. Force IMDSv2 with a hop limit of 1. On AWS set HttpTokens: required and HttpPutResponseHopLimit: 1 so the token exchange cannot survive a proxy hop. GCP and Azure have their own metadata protections; turn them on.
4. Allowlist outbound route URIs. Reject routes that point at link-local, loopback, or RFC 1918 ranges unless you genuinely need them. This holds regardless of how a route gets injected.
5. Audit the live routes. From an authenticated, internal context, read back the active route definitions and look for upstream URIs that should not be there.
6. Keep instance roles small. A leaked IMDS credential should not be able to touch unrelated buckets, run arbitrary serverless functions, or climb to a higher-privileged role.

Responsible-disclosure note

CVE-2025-41243 is a public CVE with public PoCs, handled through the vendor's standard process. This write-up draws only on public material: the CVE record, the official advisory, the published SCG source, and public third-party analysis. It includes no payloads, no route-injection syntax, and no reproduction scripts, and it discloses nothing new. The aim is to help teams judge their own exposure and apply the right fix. If you run a cloud-hosted Spring Cloud Gateway with management.endpoints.web.exposure.include: gateway and no authentication on the actuator, treat that as a critical misconfiguration on its own terms. It has been a serious surface since 2022, with or without this CVE.

References

• Spring Security advisory — CVE-2025-41243
• NVD — CVE-2025-41243
• psytester — CVE-2025-41243 SpEL property modification analysis
• "Bring Your Own SSRF — the Gateway Actuator" (2021)
• Related prior CVE: CVE-2022-22947 (Spring Cloud Gateway actuator SpEL / SSRF)

Feng Ning is a security researcher at Innora (innora.ai). Research contact: [email protected].