CVE-2026-41854

What it actually does

This vulnerability is a server-side request forgery condition caused by incorrect host parsing in Spring Framework's UriComponentsBuilder when it is used to parse and validate externally supplied URL strings. If an application trusts the parsed host value for allowlisting, blocklisting, redirects, callbacks, webhooks, URL fetchers, or similar security decisions, a crafted URL may be interpreted differently by validation logic than by the component that later makes the outbound request. The practical result is that an attacker may cause the server to send requests to unintended destinations, potentially including internal services, loopback interfaces, cloud metadata endpoints, or attacker-controlled infrastructure. The CVSS score is moderate because exploitation requires a vulnerable application pattern and user or application interaction, and the expected confidentiality and integrity impact is limited.

Why it matters to the business

Organizations using affected Spring Framework versions may have applications that can be tricked into making unauthorized outbound requests if they validate user-supplied URLs with the vulnerable parsing behavior. The main business risk is exposure of internal-only services, credentials from metadata endpoints, or sensitive integration endpoints, especially in applications that process webhooks, import remote files, fetch images, validate callback URLs, or perform URL-based redirects. The current public exploitation signal is low: EPSS is 0.00123 with no 30-day growth, no known CISA KEV listing, no ransomware association, and no reported mature exploit, but affected Spring Framework versions are common in enterprise Java applications, so the issue should still be assessed during normal patch and secure-code review cycles.

How an attack unfolds

An attacker first identifies an application feature that accepts a URL from an external user, such as a webhook registration, URL preview, remote file import, image fetch, SSO callback configuration, or redirect validation flow. The attacker then submits a specially crafted URL that causes UriComponentsBuilder to parse the host in a way that satisfies the application's validation rules while the eventual outbound HTTP client or downstream component resolves the request to a different target. If the application permits the URL, the server initiates a request from its own network location. The attacker may use this to reach internal services that are not exposed to the internet, probe internal network behavior, access cloud metadata endpoints, or relay requests to attacker-controlled infrastructure. Successful exploitation depends on the application using affected Spring Framework versions and relying on UriComponentsBuilder output for security-sensitive URL validation.

How to fix it

Upgrade Spring Framework to a vendor-confirmed fixed release outside the affected ranges. The affected ranges are Spring Framework 7.0.0 through 7.0.7 and 6.2.0 through 6.2.18. Because no exact fixed versions were provided in the input, confirm the fixed release from the official Spring advisory or vendor distribution channel before deploying. In addition to upgrading, review application code for URL validation paths that use UriComponentsBuilder with externally supplied input. Do not rely on string parsing alone for SSRF protection. Normalize and validate URLs with a single canonical parser, enforce explicit scheme allowlists such as https only where possible, perform DNS resolution and IP range checks immediately before connection, block loopback, link-local, private, multicast, and cloud metadata address ranges, and enforce egress controls at the network layer. Where URL fetching is required, proxy outbound requests through a controlled service that applies centralized SSRF protections.

How to confirm the fix worked

Confirm exposure by inventorying applications that run Spring Framework 7.0.0-7.0.7 or 6.2.0-6.2.18 and that accept externally supplied URLs. Use dependency tooling such as Maven, Gradle, SBOM scanners, SCA platforms, or container image scanners to identify affected Spring Framework artifacts. Validate remediation by confirming the application no longer includes affected Spring Framework versions after rebuild and redeployment. Review code paths using UriComponentsBuilder.fromUriString, UriComponentsBuilder.fromHttpUrl, or equivalent URL parsing and validation logic for security-sensitive decisions. Perform safe SSRF validation tests in a controlled environment by submitting URLs that attempt to resolve to loopback, private RFC1918 ranges, IPv6 loopback, link-local metadata addresses, and cloud metadata hostnames; patched and properly mitigated applications should reject these inputs and should not initiate outbound requests to restricted destinations. Also verify outbound firewall or proxy logs show denied attempts for prohibited address ranges.

Typical attack path

1. Find an externally reachable application feature that accepts user-controlled URLs.
2. Determine whether the application validates URLs using Spring Framework UriComponentsBuilder before making outbound requests or accepting the URL.
3. Craft a URL that exploits host parsing ambiguity so validation sees an allowed host while the request is ultimately directed elsewhere.
4. Submit the crafted URL through the vulnerable feature.
5. Observe whether the server makes an outbound request to an unintended internal, metadata, loopback, or attacker-controlled destination.
6. Use the resulting server-side request capability to enumerate reachable services, retrieve limited sensitive data, or influence backend integrations.

How to detect it

To determine whether exploitation has already occurred, review application access logs for requests to features that accept URLs, especially parameters or JSON fields containing full URLs, callback addresses, webhook URLs, redirect destinations, import links, image URLs, or preview targets. Correlate those inbound requests with outbound proxy, firewall, DNS, cloud flow, and application HTTP client logs from the same time window. Look for outbound requests from application servers to loopback addresses, private IP ranges, link-local addresses, cloud metadata endpoints, unusual ports, or attacker-controlled domains immediately after a user-supplied URL was submitted. Review application logs for parsing errors, rejected URL validation messages, unexpected redirects, or HTTP client exceptions involving ambiguous hosts, encoded delimiters, userinfo syntax, IPv6 notation, or mixed canonicalization. In cloud environments, examine metadata service access logs or instance role credential usage for unusual calls following suspicious URL submissions. No public threat actor exploitation has been reported in the supplied data, so detection should focus on SSRF behavior and anomalous egress rather than known campaign-specific indicators.

• 169.254.169.254
• http://169.254.169.254
• https://169.254.169.254
• metadata.google.internal
• http://metadata.google.internal
• 169.254.170.2
• 100.100.100.200
• 127.0.0.1
• http://127.0.0.1
• localhost
• http://localhost
• [::1]
• http://[::1]
• ::ffff:169.254.169.254
• 0.0.0.0
• file://
• gopher://
• dict://
• ftp://
• @169.254.169.254
• @localhost
• %40localhost
• %40169.254.169.254

What your security team should do

• Inventory Spring Framework usage across applications, containers, and build artifacts, prioritizing externally reachable services that accept user-supplied URLs.
• Upgrade affected applications to vendor-confirmed fixed Spring Framework versions as part of the next regular patch cycle, or faster for internet-facing URL-fetching workflows.
• Search code for UriComponentsBuilder usage in URL validation, redirect, webhook, callback, import, preview, and remote-fetch features.
• Add defense-in-depth SSRF controls: URL scheme allowlists, canonical host validation, DNS rebinding protections, IP range blocking, and centralized egress proxy enforcement.
• Block direct application egress to cloud metadata endpoints, loopback, link-local, private network ranges, and administrative service ports unless explicitly required.
• Add monitoring for unusual outbound requests from application servers to internal IP ranges, metadata services, localhost, and rarely contacted domains.
• Because KEV, ransomware, exploit maturity, and EPSS signals are currently low, prioritize based on exposure and application behavior rather than score alone.