CVE-2024-22262

What it actually does

This flaw affects applications that parse attacker-supplied URLs with Spring's UriComponentsBuilder and then make security decisions based on the parsed host. A crafted URL can cause the application's validation logic to see an allowed host while a downstream browser, HTTP client, proxy, or redirect target interprets the URL differently. The result can be an open redirect, where users are sent to an attacker-controlled site, or server-side request forgery (SSRF), where the server makes requests to unintended internal or external destinations after the URL appears to pass host validation. The primary risk is loss of confidentiality and integrity; availability impact is not the main concern.

Why it matters to the business

An affected application may unintentionally redirect users to phishing pages or allow attackers to make the server contact sensitive internal services, cloud metadata endpoints, administrative interfaces, or third-party systems. This can lead to credential theft, account takeover, data exposure, unauthorized internal access, and abuse of trusted application infrastructure. Although this issue is not currently listed in CISA KEV and public exploit maturity is reported as none, the weakness is remotely reachable in common URL-handling patterns and has a high CVSS score, so internet-facing applications and packages should be upgraded promptly. The listed Chainguard and Wolfi cloudflared packages are fixed in 2024.1.0-r4.

How an attack unfolds

An attacker first identifies an endpoint that accepts a URL from a request parameter, header, callback field, webhook configuration, login return target, image fetcher, document importer, or similar externally controlled input. The application parses that URL with UriComponentsBuilder and checks whether the parsed host is on an allowlist or otherwise acceptable. The attacker submits a specially constructed URL that takes advantage of parser differences: the application believes the host is trusted, but the component that later follows the redirect or performs the outbound request resolves the destination as attacker-controlled or internal. In an open redirect scenario, the attacker sends a crafted link to a user; after the application approves the URL, it issues a redirect to a malicious site that can impersonate a trusted workflow. In an SSRF scenario, the attacker causes the server to fetch a protected internal URL, potentially exposing sensitive responses, tokens, metadata, or enabling interaction with internal services.

How to fix it

Upgrade affected packages to fixed versions: cloudflared (Chainguard) 2024.1.0-r4 or later, and cloudflared (Wolfi) 2024.1.0-r4 or later. For applications using Spring URL parsing directly, upgrade the Spring Framework components that contain the corrected UriComponentsBuilder behavior according to the vendor advisory. In addition to upgrading, avoid making security decisions from one URL parser and then using the URL with another parser or client that may interpret it differently. Normalize and re-parse URLs with the same component that will actually perform the redirect or request, enforce strict allowlists on scheme and host, reject userinfo, ambiguous delimiters, encoded delimiters, backslashes, relative URLs, non-HTTP schemes, and private/link-local destinations when SSRF is possible. For SSRF-sensitive flows, use network egress controls, DNS/IP allowlisting after resolution, block cloud metadata addresses, and prevent redirects during server-side fetches unless every hop is validated.

How to confirm the fix worked

Confirm that all affected Chainguard and Wolfi cloudflared packages are upgraded to 2024.1.0-r4 or later. Validate container images, SBOMs, package manifests, and runtime package inventories rather than relying only on source repositories. For application code, search for UriComponentsBuilder usage where the input is externally controlled and the parsed host is used for allowlist validation before redirecting or making outbound HTTP requests. Add regression tests using malformed, encoded, userinfo-containing, backslash-containing, and delimiter-confusion URLs to ensure validation rejects ambiguous inputs and that the final request destination is the same host that was validated. Confirm SSRF defenses by testing that requests to loopback, RFC1918, link-local, and cloud metadata IP ranges are blocked even when supplied through redirects or encoded hostnames.

Typical attack path

1. Find an application endpoint that accepts an externally supplied URL and uses it for redirecting, callbacks, fetching remote content, webhooks, imports, or proxying.
2. Craft a URL that appears to have an allowed host when parsed by UriComponentsBuilder but is interpreted differently by the component that later uses the URL.
3. Submit the crafted URL through a query parameter, form body, API request, header, or stored configuration field.
4. Bypass the application's host validation because the parsed host appears trusted.
5. Trigger the application to either redirect a user to the attacker-controlled destination or make a server-side request to an unintended internal or external destination.
6. Use the resulting redirect for phishing/session abuse or use the SSRF behavior to access internal services, metadata endpoints, or sensitive network resources.

How to detect it

Look for evidence in both inbound application traffic and outbound network activity. In web access logs, WAF logs, API gateway logs, and application logs, search for requests to redirect, callback, webhook, import, preview, proxy, or URL-fetching endpoints where URL parameters contain unusual delimiters, encoded characters, embedded credentials, backslashes, bracket characters, or multiple apparent hosts. For open redirect abuse, correlate inbound requests containing suspicious URL parameters with HTTP 30x responses and Location headers pointing to unexpected external domains. For SSRF abuse, correlate inbound requests containing supplied URLs with outbound HTTP, DNS, or proxy activity from the application to internal IP ranges, localhost, link-local addresses, cloud metadata endpoints, administrative ports, or domains not normally contacted by the service. Review authentication, session, and fraud telemetry for users who followed redirects to lookalike domains. If available, examine HTTP client logs for final resolved URLs after redirects, not just the originally validated URL. There are no universal file, process, or registry artifacts for this vulnerability; exploitation evidence is usually found in request logs, redirect Location headers, DNS logs, egress proxy logs, and application-specific URL-fetch logs.

• UriComponentsBuilder
• returnUrl=
• redirect_uri=
• redirectUrl=
• redirect=
• next=
• target=
• url=
• uri=
• callback=
• webhook=
• %40
• @
• %5c
• %5C
• \\
• %2f%2f
• %2F%2F
• 127.0.0.1
• localhost
• 0.0.0.0
• 169.254.169.254
• metadata.google.internal
• 169.254.170.2
• [::1]

What your security team should do

• Prioritize upgrading cloudflared Chainguard and Wolfi packages to 2024.1.0-r4 or later in all images and deployments.
• Inventory applications that accept user-provided URLs and use them for redirects, callbacks, webhooks, imports, previews, proxying, or server-side fetches.
• Review code paths using Spring UriComponentsBuilder with host validation, especially where the validated URL is later passed to a browser redirect, HTTP client, proxy, or integration service.
• Add compensating controls for SSRF-prone features: strict egress filtering, metadata service blocking, DNS rebinding protections, redirect disabling, and private IP range denial.
• Add application-layer validation rules to reject ambiguous URL syntax, encoded delimiters, userinfo, backslashes, unsupported schemes, and relative or scheme-relative URLs.
• Monitor access logs and outbound proxy/DNS logs for suspicious URL parameters and unexpected server-side connections to internal, link-local, loopback, or newly registered external domains.
• If exploitation is suspected, preserve web access logs, application logs, outbound HTTP proxy logs, DNS resolver logs, WAF events, and cloud metadata access logs for forensic review.