CVE-2026-15075 in Vert.x
Summary
by MITRE • 07/14/2026
In Eclipse Vert.x versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), DefaultRedirectHandler (vertx-core) propagates all request headers as-is across cross-origin HTTP 30x redirects. Only Content-Length is stripped; no origin comparison (scheme, host, port) is performed before copying headers to the redirect target. As a result, credential headers, including Authorization, Cookie, Proxy-Authorization, and arbitrary custom headers such as X-API-Token, are forwarded to the redirect destination without the caller's knowledge.
An attacker who can cause a Vert.x HttpClient to issue a request that is redirected to an attacker-controlled host (for example, by supplying a URL to a webhook dispatcher, image proxy, or microservice URL fetcher) can capture bearer tokens, basic-auth credentials, session cookies, and API keys attached to the original request.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/14/2026
The vulnerability described affects Eclipse Vert.x versions 4.5.29 and earlier in the 4.x branch and 5.1.4 and earlier in the 5.x branch, specifically within the DefaultRedirectHandler component of vertx-core. This flaw represents a critical security weakness that enables unauthorized information disclosure through improper handling of HTTP redirect operations. The vulnerability stems from inadequate validation of cross-origin redirects where request headers are blindly propagated to destination hosts without proper origin verification. According to CWE-201, this constitutes an information exposure through improper header handling during HTTP redirection processes.
The technical implementation flaw occurs within the DefaultRedirectHandler's redirect processing logic which fails to perform origin comparison checks before forwarding request headers to redirect destinations. While the system does strip Content-Length headers as a protective measure, it neglects to validate whether the target host matches the original request's scheme, host, and port parameters. This omission allows credential headers including Authorization, Cookie, Proxy-Authorization, and custom headers such as X-API-Token to be automatically forwarded to any destination specified in the redirect response. The mechanism operates without knowledge of the caller's intent or awareness of potentially malicious redirection targets.
The operational impact of this vulnerability extends beyond simple information disclosure to encompass full credential compromise across multiple authentication mechanisms. An attacker capable of controlling redirect destinations can capture bearer tokens, basic-auth credentials, session cookies, and API keys that were originally present in the client request headers. This creates a pathway for unauthorized access to protected resources, session hijacking, and privilege escalation attacks. The vulnerability is particularly concerning in environments where Vert.x applications interact with untrusted external services or process user-provided URLs through webhook dispatchers, image proxies, or microservice URL fetchers. According to ATT&CK technique T1566, this represents a form of credential harvesting through malicious redirection.
Mitigation strategies should focus on implementing proper origin validation before header forwarding during HTTP redirects. Organizations should upgrade to patched versions of Eclipse Vert.x where the DefaultRedirectHandler has been modified to validate redirect origins against the original request parameters. Alternative approaches include disabling automatic redirects in applications that handle sensitive credentials, implementing custom redirect handlers with explicit header filtering, or configuring network-level controls to prevent cross-origin redirections. Security teams should also consider deploying monitoring solutions to detect unusual redirect patterns and implement proper access controls for URL-fetching components within their applications. The vulnerability demonstrates the importance of validating all redirect operations in web applications and aligns with security best practices outlined in OWASP Top Ten Project recommendations for preventing insecure redirects and forwarders.