CVE-2024-22243

What it actually does

This flaw affects applications that parse attacker-controlled URLs with Spring's UriComponentsBuilder and then make security decisions based on the parsed host. A crafted URL can be interpreted differently by the validation logic than by the component that later redirects to or connects to the URL. If the application uses the URL for navigation, the result can be an open redirect to an attacker-controlled destination; if the application performs a server-side request, the result can be server-side request forgery, allowing access to internal services, cloud metadata endpoints, or trusted network locations that should not be reachable by the attacker.

Why it matters to the business

Successful exploitation can let attackers abuse a trusted application to redirect users to phishing or malware sites, or force the application server to make requests into private networks and sensitive internal endpoints. The CVSS score is high, but this is not listed in CISA KEV, is not identified as ransomware-used, and the provided EPSS is relatively low, so prioritize based on whether exposed applications accept user-supplied URLs for redirects, webhooks, import/fetch features, link previews, OAuth-style return URLs, or integrations. The supplied affected-product metadata appears to list Ubuntu kernel packages, which does not align with the described UriComponentsBuilder issue; organizations should verify both OS package advisories and application dependency inventories before declaring exposure closed.

How an attack unfolds

An attacker first identifies an endpoint that accepts a full or partial URL from a user-controlled source, such as a query parameter, form field, webhook target, callback URL, redirect URL, or API field. The application parses that value with UriComponentsBuilder and checks whether the parsed host is in an allowed list. The attacker submits a specially formatted URL that passes the application's host validation but is later interpreted by a redirect mechanism, HTTP client, browser, proxy, or downstream library as pointing somewhere else. For open redirect scenarios, the victim is sent through the trusted application to an attacker-controlled site. For SSRF scenarios, the vulnerable server makes the request itself, potentially reaching internal hosts such as localhost, RFC1918 addresses, Kubernetes or cloud metadata services, or management APIs. The attacker then uses responses, timing, DNS interactions, or error messages to confirm reachability and, where possible, extract data or trigger privileged internal actions.

How to fix it

Upgrade affected Spring Framework dependencies to versions containing the URL parsing fixes, such as Spring Framework 6.1.4 or later, 6.0.17 or later, and 5.3.32 or later where applicable; also upgrade dependent frameworks that bundle or pin Spring Framework. Review application logic that accepts externally supplied URLs: do not rely on a single parsed host check followed by reuse of the original string; normalize and reconstruct the URL from parsed components after validation; enforce strict allowlists of scheme, host, and port; reject userinfo, backslashes, encoded delimiters, malformed bracket characters, redirects to private IP ranges, and non-HTTP schemes unless explicitly required. For SSRF-prone features, route outbound traffic through an egress proxy with destination allowlisting and block access to localhost, RFC1918, link-local, multicast, and cloud metadata addresses. For open redirect-prone features, prefer relative paths or server-side mapped destination identifiers instead of arbitrary URLs. The provided fixed-version list includes Ubuntu package versions, including linux 3.13.0-63.103, linux-aws 4.4.0-1002.2, linux-lts-xenial 4.4.0-13.29~14.04.1, linux 4.2.0-16.19, linux-aws 4.4.0-1001.10, linux-gke 4.4.0-1003.3, linux-hwe 4.8.0-36.36~16.04.1, linux-raspi2 4.2.0-1013.19, linux-snapdragon 4.4.0-1012.12, linux-lts-utopic 3.16.0-50.66~14.04.1, linux-lts-vivid 3.19.0-28.30~14.04.1, and linux-lts-wily 4.2.0-18.22~14.04.1; because those package names do not match the described Spring vulnerability, treat them as advisory data to validate rather than sufficient remediation for this specific application-layer issue.

How to confirm the fix worked

Confirm whether applications include vulnerable Spring Framework versions by inspecting build manifests and dependency output, such as Maven dependency:tree, Gradle dependencies, SBOMs, container image manifests, and packaged JAR metadata. Verify that deployed applications are running patched Spring versions, not only that source repositories have been updated. Search code for UriComponentsBuilder usage combined with host allowlist checks and later redirects or HTTP client calls. Test representative URL-handling endpoints with benign malformed URLs containing encoded delimiters, userinfo syntax, backslashes, brackets, localhost, private IPs, and controlled external callback domains; the application should reject unsafe values or reconstruct a safe canonical URL. Validate egress controls by confirming that application servers cannot reach 127.0.0.1, 169.254.169.254, RFC1918-only services, or unauthorized external destinations through user-supplied URL features.

Typical attack path

1. Find an application endpoint that accepts an externally supplied URL parameter or body field.
2. Determine whether the application validates the URL host before using the URL in a redirect or server-side request.
3. Craft URLs containing ambiguous delimiters, encoded characters, userinfo-like syntax, backslashes, brackets, or nested URL values to create a parsing discrepancy.
4. Submit the crafted URL and observe whether validation accepts it while the actual request or redirect goes to a different destination.
5. For open redirect, lure a user to click a trusted-looking link that ultimately redirects to an attacker-controlled site.
6. For SSRF, direct the server toward internal services, loopback addresses, link-local metadata endpoints, or attacker-controlled callback infrastructure.
7. Use response content, HTTP status codes, timing, DNS logs, or out-of-band callbacks to confirm impact and expand access.

How to detect it

To determine whether exploitation already occurred, review web access logs, application logs, WAF/API gateway logs, reverse proxy logs, outbound proxy logs, DNS resolver logs, cloud metadata access logs, and HTTP client telemetry from applications that accept URL parameters. Focus on endpoints and fields named like url, uri, target, redirect, redirect_uri, return, returnUrl, callback, callbackUrl, webhook, next, dest, destination, continue, link, image, import, fetch, or feed. Look for requests where those fields contain a full URL with encoded separators, backslashes, userinfo delimiters, bracket characters, nested URLs, localhost, link-local addresses, RFC1918 addresses, or unusual ports. For SSRF, correlate inbound requests carrying suspicious URL values with outbound connections from the application to internal IPs, cloud metadata endpoints, unexpected DNS names, collaborator/canary domains, or attacker-controlled infrastructure. For open redirect, look for 30x responses where the Location header points to an untrusted external domain after an inbound request to a trusted redirect endpoint. Also review application errors from URL parsing, HTTP client exceptions, connection refused/timeouts to internal hosts, and DNS lookups that immediately follow suspicious inbound requests.

• 169.254.169.254
• metadata.google.internal
• 100.100.100.200
• 127.0.0.1
• localhost
• 0.0.0.0
• [::1]
• file://
• gopher://
• ftp://
• dict://
• jar://
• http://169.254.169.254
• http://127.0.0.1
• http://localhost
• https://localhost
• %2f%2f
• %5c
• %5C
• \@
• %40
• [@
• ]@
• redirect_uri=http
• redirect_uri=https
• returnUrl=http
• returnUrl=https
• callbackUrl=http
• callbackUrl=https
• webhook=http
• webhook=https
• url=http
• url=https
• target=http
• target=https
• destination=http
• destination=https
• next=http
• next=https
• Location: http://
• Location: https://
• UriComponentsBuilder
• Connection refused
• Read timed out
• UnknownHostException
• java.net.ConnectException
• java.net.SocketTimeoutException

What your security team should do

• Prioritize externally reachable applications that accept user-supplied URLs for redirects, callbacks, webhooks, import/fetch functions, OAuth/SAML return destinations, link previews, or integration targets.
• Inventory Spring Framework versions in source, build artifacts, containers, and running services; upgrade to fixed Spring versions and rebuild dependent applications.
• Review and harden URL validation code so validation is performed on canonicalized components and the validated/reconstructed URL, not the original untrusted string, is used.
• Add WAF, API gateway, or application-layer detections for suspicious URL parameters containing encoded delimiters, userinfo syntax, backslashes, brackets, localhost, private IP ranges, and cloud metadata addresses.
• Enforce outbound network controls for application workloads, including egress allowlisting and explicit blocks for link-local metadata services and internal management networks.
• Hunt historical web, application, proxy, DNS, and egress logs for suspicious URL parameters and unexpected outbound requests around exposed URL-processing endpoints.
• Treat the supplied Ubuntu kernel package metadata as potentially inconsistent with the described vulnerability and verify remediation against authoritative Spring/application dependency advisories.