CVE-2024-22262 - How A Flaw In UriComponentsBuilder Can Lead To Open Redirects And SSRF Attacks

In 2024, researchers uncovered a critical vulnerability affecting applications that use Spring’s UriComponentsBuilder for parsing and validating externally provided URLs. Registered as CVE-2024-22262, this issue exposes applications to dangerous attacks such as open redirects (CWE-601) and Server-Side Request Forgery (SSRF). Even if your code checks the URL's host for safety, you might still be at risk — unless you update or carefully validate your input.

This is closely related to CVE-2024-22259 and CVE-2024-22243, but features a different method of input manipulation.

This article explains the vulnerability in simple terms, shows how attackers might exploit it, and provides the code snippets and references you need to understand and fix your code.

What Is CVE-2024-22262?

CVE-2024-22262 is a vulnerability in how UriComponentsBuilder parses "weird" or crafted URLs. If your code gets a URL (for example, from a REST API query parameter), uses UriComponentsBuilder to parse it, and then validates the host or scheme before using it, your checks may not work as intended. An attacker might design input that fools your validation, allowing them to:

Why Does This Happen?

When parsing special URL structures, UriComponentsBuilder can get confused about what the actual host is. This allows attackers to craft URLs where:

Suppose you check incoming URLs like this

String userUrl = request.getParameter("redirect");
UriComponents uri = UriComponentsBuilder.fromUriString(userUrl).build();
String host = uri.getHost();

if ("trusted.com".equalsIgnoreCase(host)) {
    // Proceed with redirect
    response.sendRedirect(userUrl);
} else {
    // Host not allowed
    response.setStatus(400);
}

At a glance, the code seems to prevent open redirects—you only allow a known host.

Payload

http://trusted.com@evil.com

UriComponentsBuilder sees the host as trusted.com (before the @)

- But browsers and HTTP clients treat the right side of the @ as the real host, so they go to evil.com

Result:
Your validation passes, but the user is sent to evil.com.

If you use the checked URL for internal requests

RestTemplate restTemplate = new RestTemplate();
restTemplate.getForObject(userUrl, String.class);

An attacker could get your server to connect to arbitrary locations (SSRF), including internal-only servers.

See how the attack happens in practice

// Vulnerable Spring Controller example

@GetMapping("/redirect")
public void redirectToUrl(@RequestParam String url, HttpServletResponse response) throws IOException {
    UriComponents uri = UriComponentsBuilder.fromUriString(url).build();
    String host = uri.getHost();

    if ("trusted.com".equalsIgnoreCase(host)) {
        response.sendRedirect(url); // Vulnerable!
    } else {
        response.sendError(400, "Untrusted host");
    }
}

What the attacker sends

/redirect?url=http://trusted.com@evil.com

References

- CWE-601: Open Redirect
- Spring Security Advisory: CVE-2024-22259
- Spring Security Advisory: CVE-2024-22243

1. Use Latest Spring Libraries

Spring development team has released patches for this and related CVEs. Update to the latest Spring Framework and Spring Security.

2. Validate URLs Correctly

Do not trust UriComponentsBuilder for security checks on user-supplied hostnames. Instead, consider parsing the URL as raw text or with stricter libraries. Check for presence of @, check raw input, or use allowlists and more comprehensive validation.

Improved Code Example

@GetMapping("/safe-redirect")
public void safeRedirectToUrl(@RequestParam String url, HttpServletResponse response) throws IOException {
    // Reject URL if it contains '@'
    if (url.contains("@")) {
        response.sendError(400, "URL contains unsafe characters");
        return;
    }
    // Parse and check host as before, but after initial filtering
    UriComponents uri = UriComponentsBuilder.fromUriString(url).build();
    String host = uri.getHost();

    // Use a strict allowlist
    List<String> allowed = Arrays.asList("trusted.com");
    if (allowed.contains(host)) {
        response.sendRedirect(url);
    } else {
        response.sendError(400, "Untrusted host");
    }
}

3. SSRF Protections

If you use user-supplied URLs for server-side requests (for example, with RestTemplate, HttpClient, etc.), never trust user input. Consider using service proxies, explicit allowlists, and reject all local addresses.

Summary

CVE-2024-22262 is a serious bug for web apps using Spring’s UriComponentsBuilder for host validation of user-supplied URLs. Attackers can bypass your checks with special payloads, causing open redirects or SSRF. Update your frameworks and always validate URLs with more than library parsing—look closely at user input and use defense-in-depth.

Stay safe: Patch, validate, and be skeptical of all URLs from users.


*This post is exclusive and written for clarity, with all key points and fixes covered in simple American English. For more background, check the official Spring advisory for CVE-2024-22259 and for CVE-2024-22243.*

Timeline

Published on: 04/16/2024 06:15:46 UTC
Last modified on: 06/28/2024 03:55:23 UTC