CVE-2024-21510

What it actually does

The flaw is an open redirect caused by trusting the untrusted X-Forwarded-Host HTTP header when constructing redirect destinations. A remote unauthenticated attacker can supply an arbitrary host value in that header and cause affected redirect logic to emit a Location header pointing to an attacker-controlled domain. The direct impact is integrity loss of redirect behavior and possible confidentiality loss if users are induced to follow the redirect and disclose credentials, tokens, or sensitive referrer data. In deployments behind reverse proxies, caches, or routing layers that forward or act on X-Forwarded-Host without normalization, the same weakness can contribute to cache poisoning or routing-based server-side request forgery patterns.

Why it matters to the business

Exploitation can make legitimate services send users to malicious sites, enabling phishing, credential theft, brand abuse, and reduced trust in customer-facing web applications. If a reverse proxy or cache stores poisoned redirect responses, multiple users may be affected without each receiving a separate attacker-crafted request. The issue is not currently listed in CISA KEV, has low EPSS likelihood, and no known ransomware association, but it has been public for a significant period and is simple to test, so internet-facing applications and proxy-exposed services should still be remediated during normal vulnerability SLAs. The supplied product metadata references Ubuntu ActiveMQ packages while the vulnerability description references Sinatra; organizations should validate both application dependency and OS package applicability against authoritative vendor advisories before closing the finding.

How an attack unfolds

An attacker identifies an affected web endpoint that performs a redirect, such as login, logout, callback, canonical-host, or trailing-slash redirect behavior. The attacker sends a request to that endpoint through a proxy path that preserves X-Forwarded-Host and sets the header to an attacker-controlled domain. The vulnerable application trusts that header as if it represented the legitimate external host and generates a 3xx response whose Location header points to the attacker domain. The attacker then delivers a link or causes a victim browser, crawler, or cache to request the vulnerable endpoint. If a victim follows the redirect, the attacker can present a convincing phishing page or collect sensitive data included in the URL or referrer. If an intermediary cache stores the malicious redirect, later users may be redirected even without attacker-supplied headers. In more complex proxy topologies, attacker-controlled host routing may also influence backend selection or internal request routing, creating an SSRF-like primitive.

How to fix it

Upgrade affected software to fixed vendor versions and remove vulnerable dependency versions from application builds. For the supplied package data, Ubuntu 14.04 LTS ActiveMQ is listed as fixed in 5.6.0+dfsg-1+deb7u2build0.14.04.1 and Ubuntu 16.04 LTS ActiveMQ is listed as fixed in 5.13.2+dfsg-2; deduplicate package findings and confirm applicability with the relevant Ubuntu security notice. For applications using Sinatra, upgrade to a non-vulnerable Sinatra release as specified by the upstream RubyGems/vendor advisory and regenerate lockfiles. As defense in depth, configure reverse proxies to overwrite rather than pass through client-supplied X-Forwarded-Host, accept forwarded headers only from trusted proxies, and set an explicit canonical host allowlist in application configuration. Redirect handlers should use relative redirects where possible or validate absolute redirect destinations against an allowlist of approved domains. Disable caching of 3xx responses that vary by Host, X-Forwarded-Host, scheme, or user-controlled inputs unless the cache key explicitly includes and normalizes those values.

How to confirm the fix worked

Confirm package remediation by checking installed package versions with the platform package manager and verifying they are at or above the fixed versions listed by the authoritative vendor advisory. For application dependencies, inspect Gemfile.lock, dependency manifests, container layers, SBOMs, and deployed artifact metadata to ensure vulnerable Sinatra versions are absent. Functionally validate by sending a request to known redirecting endpoints with a header such as X-Forwarded-Host: attacker.example and confirming the response does not produce a Location header on attacker.example. Repeat the test through the same load balancer, CDN, reverse proxy, and cache path used in production because the issue depends on header handling across the request chain. Verify proxy configuration strips, normalizes, or overwrites X-Forwarded-Host from untrusted clients and that only trusted upstream infrastructure can set forwarded headers. Check cache behavior by ensuring malicious redirect responses are not stored or replayed to later requests without the crafted header.

Typical attack path

1. Find an internet-accessible endpoint in the affected application that performs redirects.
2. Send test requests with a crafted X-Forwarded-Host header containing an external attacker-controlled host.
3. Confirm the response returns a 3xx status with a Location header using the attacker-supplied host.
4. Create a lure URL or request flow that causes a victim, crawler, or shared cache to hit the vulnerable redirect endpoint.
5. Redirect the victim to a phishing site, malware landing page, token collection endpoint, or lookalike domain.
6. Where caching is present, attempt to poison cached redirect responses so subsequent users are redirected without needing the malicious header.
7. Where host-based routing is present, attempt to influence proxy/backend routing using the manipulated forwarded host value.

How to detect it

Review HTTP access logs, reverse proxy logs, CDN logs, WAF events, and application logs for requests to redirecting endpoints that include an X-Forwarded-Host header not matching the expected public domain set. Correlate those requests with 3xx responses, especially where the Location response header points to an external or newly observed domain. Examine cache/CDN logs for stored or served redirects with unexpected Location hosts, high cache-hit counts on redirect responses, or cache keys that omit Host and X-Forwarded-Host. Investigate authentication, OAuth, SSO, logout, password reset, callback, and canonicalization endpoints first because they commonly perform redirects and are useful for phishing. For suspected exploitation, collect full request/response headers if available, compare X-Forwarded-Host to Host and the emitted Location header, and identify source IPs, user agents, and target external domains used repeatedly. Also review downstream telemetry for users navigating from legitimate service URLs to unexpected domains immediately after receiving HTTP 301, 302, 303, 307, or 308 responses.

• X-Forwarded-Host: http://
• X-Forwarded-Host: https://
• X-Forwarded-Host: //
• X-Forwarded-Host: localhost
• X-Forwarded-Host: 127.0.0.1
• X-Forwarded-Host: 169.254.169.254
• X-Forwarded-Host: metadata.google.internal
• X-Forwarded-Host: attacker.example
• Location: http://
• Location: https://
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• X-Forwarded-Host
• XFH
• 301.*X-Forwarded-Host
• 302.*X-Forwarded-Host
• Location: .*//.*@
• Location: //

What your security team should do

• Prioritize externally reachable web applications and services behind reverse proxies, CDNs, or shared caches, even though KEV is false and EPSS is low.
• Resolve the metadata mismatch by validating whether exposure is through Sinatra application dependencies, Ubuntu ActiveMQ packages, or both, using vendor advisories and SBOM data.
• Upgrade affected packages to fixed versions and rebuild/redeploy dependent applications, containers, and base images.
• Harden edge infrastructure to drop client-supplied X-Forwarded-Host and inject a trusted value only at the controlled proxy boundary.
• Review redirect endpoints for allowlisted destinations and replace absolute redirects with relative redirects where feasible.
• Search historical web, proxy, CDN, WAF, and application logs for requests containing unusual X-Forwarded-Host values followed by 3xx responses.
• Inspect cache/CDN configuration for cached 301, 302, 303, 307, or 308 responses that could have been keyed without forwarded-host normalization.
• Add regression tests that send hostile Host and X-Forwarded-Host values to redirecting routes and fail builds if external Location headers are returned.