CVE-2024-22259

What it actually does

This vulnerability is a URL parsing and validation bypass in applications that use Spring Framework's UriComponentsBuilder to parse attacker-supplied URLs and then make security decisions based on the parsed host. A specially crafted URL can cause the application to validate one host value while the browser, redirect handler, or server-side HTTP client ultimately uses a different destination. Depending on how the parsed URL is used, this can result in an open redirect, server-side request forgery, or bypass of host allowlists intended to restrict outbound requests.

Why it matters to the business

If an affected application accepts externally supplied URLs, attackers may be able to redirect users to phishing or malware sites that appear to originate from a trusted application, or cause backend systems to make unauthorized requests to internal or sensitive services. This can expose credentials, tokens, internal metadata services, administrative interfaces, or other protected resources. The issue has a high CVSS score of 8.1, but it is not currently listed in CISA KEV and the provided EPSS score is relatively low, so remediation should be prioritized for internet-facing applications, authentication flows, redirect endpoints, webhook fetchers, URL preview features, and integrations that make outbound server-side requests.

How an attack unfolds

An attacker first identifies an endpoint that accepts a URL from a request parameter, form field, header, API body, or integration setting. The vulnerable application parses that URL with UriComponentsBuilder and checks whether the parsed host is allowed, trusted, or belongs to an expected domain. The attacker supplies a crafted URL that passes this host validation check but is interpreted differently when the application later redirects a user or makes a server-side HTTP request. In an open redirect scenario, the victim is lured into clicking a trusted application link and is then sent to an attacker-controlled site. In an SSRF scenario, the application server itself sends a request to an unintended destination, potentially including internal services, cloud metadata endpoints, or attacker-controlled infrastructure. Successful exploitation depends on the application using externally supplied URLs after validation; applications that do not accept or reuse untrusted URLs are not directly exploitable through this flaw.

How to fix it

Upgrade Spring Framework to a fixed version or commit supplied by the vendor. For the provided package data, spring-projects/spring-framework is fixed in commit df041ba032cceb9ca5c96214fe238b91c3f94f63. If consuming Spring through released artifacts rather than source, use the corresponding maintained Spring Framework fixed release for the branch in use and avoid unsupported branches. The provided Ubuntu 16.04 LTS wordpress package entry is listed as fixed in 4.3.1+dfsg-1; validate whether that package is actually relevant to the deployed application stack because the described flaw concerns Spring Framework URL parsing. As compensating controls, do not rely solely on UriComponentsBuilder host parsing for security decisions on untrusted URLs; canonicalize and validate URLs using a single authoritative parser immediately before use; enforce strict allowlists on scheme, host, and port; reject userinfo, encoded delimiters, ambiguous authority syntax, backslashes, control characters, nested URLs, and non-HTTP schemes unless explicitly required; block requests to localhost, loopback, link-local, private RFC1918 ranges, cloud metadata IPs, and internal DNS zones; and prefer server-generated redirect destinations or opaque redirect identifiers over arbitrary user-supplied URLs.

How to confirm the fix worked

Confirm dependency resolution shows a fixed Spring Framework version or the fixed commit df041ba032cceb9ca5c96214fe238b91c3f94f63 in source builds. Review code for uses of UriComponentsBuilder.fromUriString, UriComponentsBuilder.fromHttpUrl, UriComponentsBuilder.fromUri, UriComponentsBuilder.parseForwardedFor, or equivalent URL parsing where the input can be influenced by a user and the parsed host is used for allowlist decisions. Test exposed endpoints that accept URL parameters with crafted ambiguous URLs and verify they are rejected before redirecting or making outbound requests. Validate that redirects only resolve to approved destinations and that server-side URL fetch features cannot reach internal IP ranges, localhost, cloud metadata services, or attacker-controlled domains through parsing tricks. In production, confirm outbound egress controls and SSRF protections deny unintended destinations even if application-level validation fails.

Typical attack path

1. Find an application endpoint that accepts an externally supplied URL, such as a redirect target, callback URL, webhook URL, import URL, image fetch URL, or URL preview parameter.
2. Submit crafted URL payloads designed to exploit parsing differences between UriComponentsBuilder validation and the component that ultimately follows or uses the URL.
3. Confirm that the application-side host allowlist or validation check accepts the payload.
4. For open redirect, send the crafted trusted-looking link to a victim and cause the victim's browser to land on an attacker-controlled destination.
5. For SSRF, cause the server to issue an outbound request to an unintended internal, cloud metadata, or attacker-controlled endpoint.
6. Use the redirect or server-side request to steal credentials, harvest tokens, reach internal services, bypass network controls, or support a larger phishing or intrusion campaign.

How to detect it

To determine whether this was already exploited, review application access logs, reverse proxy logs, WAF events, application debug logs, outbound proxy logs, DNS resolver logs, EDR network telemetry, and cloud VPC flow logs around endpoints that accept URL-like parameters. Look for requests containing redirect, callback, next, url, uri, target, destination, continue, return, webhook, image, fetch, or import parameters with unusual URL syntax, encoded delimiters, userinfo sections, repeated schemes, backslashes, square brackets, excessive percent-encoding, or embedded trusted domains followed by attacker-controlled domains. For possible SSRF, correlate inbound requests carrying suspicious URL values with near-immediate outbound connections from the application to localhost, 127.0.0.0/8, 169.254.169.254, ::1, RFC1918 private ranges, internal DNS names, or unfamiliar external domains. For possible open redirect abuse, look for high-volume 3xx responses where the Location header points outside approved domains, especially when the inbound request includes a URL parameter. Also review authentication, password reset, email verification, and SSO-related flows for links that redirected to external domains shortly before credential misuse or suspicious login activity.

• 169.254.169.254
• metadata.google.internal
• metadata.aws.internal
• 169.254.170.2
• 127.0.0.1
• localhost
• [::1]
• file://
• gopher://
• dict://
• ftp://
• http://127.0.0.1
• http://localhost
• http://169.254.169.254
• https://169.254.169.254
• %40
• @
• %5c
• %5C
• \\
• %2f%2f
• %2F%2F
• http://http://
• https://http://
• redirect=
• redirect_uri=
• returnUrl=
• return_url=
• next=
• url=
• uri=
• target=
• destination=
• continue=
• callback=
• webhook=
• fetch=
• importUrl=

What your security team should do

• Inventory applications and services that use Spring Framework and accept externally supplied URLs for redirects, callbacks, webhooks, imports, image fetching, document fetching, or link previews.
• Prioritize internet-facing applications, authentication and SSO flows, payment or account workflows, and any feature that performs server-side outbound HTTP requests.
• Upgrade affected Spring Framework dependencies to a fixed vendor release or the provided fixed commit df041ba032cceb9ca5c96214fe238b91c3f94f63, and rebuild/redeploy all dependent services.
• Perform a focused code review for host allowlist checks based on UriComponentsBuilder output and replace fragile validation with strict canonicalization, scheme/host/port allowlists, and deny rules for internal address ranges.
• Add egress filtering for application workloads to prevent access to localhost, private networks, link-local ranges, and cloud metadata endpoints unless explicitly required.
• Add regression tests for malicious and ambiguous URL inputs so future parser or validation changes cannot reintroduce open redirect or SSRF behavior.
• Review web, application, proxy, and DNS logs for historical attempts to use unusual URL authority syntax, encoded delimiters, or requests that caused outbound connections to internal or unexpected hosts.