Eclipse Jetty CVE-2026-76184

Exploitation requires three concrete conditions stated in the advisory: (1) the target application must use Jetty HttpClient to send credentials via an Authorization header scoped to a path such as /secure and must follow HTTP redirects; (2) the attacker must be able to control or influence the redirect response returned to HttpClient; and (3) the attacker must have a malicious application deployed on the SAME domain as the target so the leaked Authorization header reaches an endpoint they control (e.g. /secure/../evil). LIMITING FACTORS: the same-domain malicious-app requirement and the need to control redirects substantially raise attack complexity (reflected as AC:H), preventing arbitrary cross-domain credential theft; applications that do not follow redirects or do not attach path-scoped credentials are unaffected.

This is a credential-disclosure flaw (CWE-200) in Eclipse Jetty's HttpClient where a non-normalized redirect path (e.g. /secure/../evil) causes the Authorization header scoped to /secure to be sent to /evil. The provided CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H) scores 8.2 (High): network-reachable, no privileges or user interaction, but high attack complexity, with high confidentiality impact and no integrity/availability impact - consistent with pure information disclosure. The high AC is well justified by the description's precondition that the attacker must both control the redirect target and already have a malicious application deployed on the same domain as the target, which materially narrows exploitability. No EPSS score, CISA KEV listing, SSVC decision, or POC was provided in the input, so the signals are not conflicting but are incomplete: the only evidence of real-world risk is the vendor (Eclipse) GHSA advisory. Bottom line - a legitimately High-severity credential leak for applications using Jetty HttpClient with credentialed, redirect-following requests, but the same-domain malicious-app precondition makes opportunistic mass exploitation unlikely; prioritize for environments where Jetty HttpClient handles authenticated outbound requests to attacker-influenceable hosts.

An application uses Jetty HttpClient to make authenticated requests (sending an Authorization header scoped to /secure) and follows server redirects. An attacker who controls a redirect response and has an app deployed under the same domain returns a redirect to /secure/../evil; HttpClient matches credentials against the literal /secure prefix instead of the normalized /evil and forwards the Authorization header to the attacker-controlled /evil endpoint, disclosing the credentials. No public exploit was identified at time of analysis.