CVE-2026-76184 in Jetty
Summary
by MITRE • 10/15/2026
In Eclipse Jetty, HttpClient may receive a redirect of the form:
```
/secure/../evil
```
If an attacker is able to control the redirects, then HttpClient matches authentication credentials against `/secure` rather than normalizing the path to `/evil`, and will therefore follow the redirect sending the `Authorization` header for `/secure` to `/evil`.
This also mean that the attacker must have an evil application deployed on the same domain as the target.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability in Eclipse Jetty's HttpClient component represents a critical flaw in path normalization logic during HTTP redirection handling, specifically affecting how authentication credentials are scoped and transmitted across redirect chains. When an HttpClient instance is configured with specific authorization headers for certain URL patterns or domains, it relies on the request URI to determine whether those credentials should be included in subsequent requests. The core technical failure occurs when the client processes a redirect response that contains path traversal sequences, such as /secure/../evil. Instead of normalizing this path to its canonical form, which would resolve to /evil, Jetty's HttpClient retains the original unnormalized structure for credential matching purposes. This behavior deviates from standard HTTP/1.1 specifications and common security expectations where logical paths should be resolved before policy enforcement decisions are made.
This architectural oversight leads directly to a privilege escalation scenario known as authorization bypass via path manipulation. An attacker who can control or influence the redirect target, typically through a vulnerable application hosted on the same domain as the intended target, can exploit this logic error. By crafting a response that redirects from a protected resource like /secure to an arbitrary endpoint using traversal sequences, the attacker tricks the HttpClient into believing it is still accessing resources within the secure scope. Consequently, the client attaches sensitive authentication credentials, such as Basic Auth tokens or Bearer JWTs intended for the restricted area, and sends them in clear text to the maliciously controlled endpoint at /evil. This results in the unauthorized exfiltration of high-privilege secrets to an attacker-controlled server.
The operational impact is severe, particularly in microservices architectures or client applications that automatically follow redirects without explicit user intervention. If a service uses Jetty HttpClient to communicate with internal APIs protected by strict access controls, an attacker compromising any application on the same host can harvest credentials for other services simply by manipulating redirect responses. This effectively neutralizes the security boundary provided by path-based authorization rules. The requirement that the evil application must be deployed on the same domain limits the attack surface somewhat compared to cross-domain attacks, but it remains a significant risk in environments where multiple applications share a single host or virtual server configuration. Attackers with local access or compromised web applications within the same origin can leverage this flaw to escalate privileges and gain unauthorized access to sensitive backend systems.
From an industry standards perspective, this vulnerability aligns closely with CWE-284 Improper Access Control, as it involves bypassing intended restrictions on resource access through manipulation of input paths. It also relates to CWE-601 URL Redirection to Untrusted Site via Open Redirect if the redirect target is externally controlled, though the primary issue here is the credential leakage rather than just redirection. In terms of MITRE ATT&CK techniques, this behavior facilitates Credential Access (T1539) by allowing an attacker to steal credentials through a trusted client application. It also touches upon Defense Evasion (T1071 Application Layer Protocol) as it abuses legitimate HTTP redirect mechanisms to bypass security monitoring and access controls.
Mitigation strategies must focus on enforcing strict path normalization before any credential matching or policy evaluation occurs. Developers should ensure that the HttpClient implementation resolves all relative paths, including those containing dot-dot sequences, into their canonical absolute forms prior to checking authorization headers against URL patterns. Upgrading to a patched version of Eclipse Jetty is the primary remediation step, as newer releases address this logic error by normalizing request URIs during redirect processing. Additionally, security teams should implement strict allow-listing for redirect targets where possible and avoid configuring broad credential scopes that cover multiple distinct applications on the same host unless absolutely necessary. Monitoring network traffic for unusual patterns of redirects involving path traversal characters can also aid in detecting exploitation attempts in real-time.