CVE-2026-76184

Overview

Eclipse Jetty is a widely used, embeddable Java web server and servlet container. It supports HTTP/1.1, HTTP/2, HTTP/3, and WebSocket, and is commonly deployed both as a standalone server and embedded within Java application runtimes and frameworks. Its jetty-client module provides HttpClient, Jetty's HTTP client API, including built-in handling of HTTP authentication and redirects.

An information exposure vulnerability (CVE-2026-76184) has been identified in the Eclipse Jetty HttpClient, which allows attackers who can influence a same-origin redirect to obtain a cached Basic authentication credential at a path outside the credential's configured scope.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects multiple versions of Eclipse Jetty.

Details

Module Info

• Product: Eclipse Jetty
• Affected packages: org.eclipse.jetty:jetty-client
• Affected versions: >=9.4.0 <=9.4.64, >=10.0.0 <=10.0.32, >=11.0.0 <=11.0.32, >=12.0.0 <=12.0.38, >=12.1.0 <=12.1.12
• GitHub repository: https://github.com/jetty/jetty.project
• Published packages: https://central.sonatype.com/artifact/org.eclipse.jetty/jetty-client
• Package manager: Maven
• Fixed in:
  • OSS Eclipse Jetty 12.0.39, 12.1.13
  • NES for Jetty v9.4.65, v10.0.33, v11.0.33

Vulnerability Info

This High-severity vulnerability is found in the org.eclipse.jetty:jetty-client package in multiple versions of Eclipse Jetty. HttpClient keeps authentication results, such as a stored or challenge-derived BasicAuthentication.BasicResult, in its HttpAuthenticationStore, each scoped to a URI. Before reapplying a cached result to a request, the store calls AbstractAuthentication.matchesURI(), which compares the scheme, host and port and then tests the path with a plain string prefix check:

public static boolean matchesURI(URI uri1, URI uri2)
{
    String scheme = uri1.getScheme();
    if (scheme.equalsIgnoreCase(uri2.getScheme()))
    {
        if (uri1.getHost().equalsIgnoreCase(uri2.getHost()))
        {
            // Handle default HTTP ports.
            int thisPort = HttpClient.normalizePort(scheme, uri1.getPort());
            int thatPort = HttpClient.normalizePort(scheme, uri2.getPort());
            if (thisPort == thatPort)
            {
                // Use decoded URI paths.
                return uri2.getPath().startsWith(uri1.getPath());
            }
        }
    }
    return false;
}

Neither path has its dot segments removed, and the prefix does not have to end at a path-segment boundary. When a server on the same origin answers with a redirect to /private/../privateevil/collect, HttpClient drops the previous Authorization header, but the raw redirect path starts with the cached scope /private/, so the client reapplies the cached credential. The server then resolves the dot segments and dispatches the request to the sibling path /privateevil/collect, which never receives the credential when requested directly. In a path-routed or multi-tenant deployment, a less-trusted application at that sibling path can capture a reusable username and password.

Mitigation

Only recent versions of Eclipse Jetty are community-supported. Only community-supported versions will receive updates to address this issue. As of January 1, 2026 the Jetty project and Webtide no longer publish Jetty 9, Jetty 10, or Jetty 11 releases to Maven Central; see the project's End-of-Life announcement.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a supported version of Eclipse Jetty (12.0.39, 12.1.13).
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• 4ra1n (finder)
• unam4 (finder)