Introduction
A flaw in Eclipse Jetty's Jakarta Authentication (JASPI) integration lets one user's authentication context leak silently into another user's request. The leak travels through ThreadLocal variables that are not cleared before a pooled thread is reused. Under normal production concurrency, a request on any Jetty server with JASPI enabled can inherit the identity and privileges of a completely unrelated earlier user. The result is privilege escalation with no attacker-controlled payload.
Eclipse Jetty is a widely deployed, high-performance Java web server and Servlet container maintained by the Eclipse Foundation. It supports HTTP/3, HTTP/2, and WebSocket, and it is embedded in major products including Apache ActiveMQ, Apache Maven, Apache Spark, Google App Engine, and Hadoop. Because Jetty is used both as a standalone server and as an embedded component, its vulnerabilities frequently have a large transitive blast radius in enterprise software.
Technical Information
Root Cause: ThreadLocal State Leakage in JaspiAuthenticator
The vulnerability, tracked as CVE-2026-5795 with a CVSS score of 7.4, is in the JaspiAuthenticator class, which bridges Jakarta Authentication (JASPI) and Jetty's internal security framework. The class is present in multiple Jetty API versions, including the org.eclipse.jetty.ee11.security.jaspi and org.eclipse.jetty.ee10.security.jaspi packages.
During authentication, JaspiAuthenticator starts checks that store the current request's authentication state in two ThreadLocal variables. In Java, ThreadLocal storage is scoped to the executing thread. Anything stored there stays for the life of the thread unless code explicitly removes it.
Certain conditions trigger an early return from the JaspiAuthenticator code path. That return skips the cleanup logic that would normally clear the two ThreadLocal variables, so the current user's authentication state stays attached to the thread.
The flaw is classified under two CWE categories:
- CWE-226 (Sensitive Information in Resource Not Removed Before Reuse): The thread, a shared resource in Jetty's thread pool, keeps sensitive authentication data after the request that created it has completed.
- CWE-287 (Improper Authentication): The next request on the contaminated thread is treated as authenticated under the wrong identity, and proper authentication verification is bypassed.
Attack Flow
Production Jetty deployments use thread pooling for performance. A finite set of worker threads handles incoming requests, and each thread is recycled after its request completes. This is standard behavior and central to how Jetty scales.
Exploitation follows four steps:
-
A legitimate user with elevated privileges sends a request that
JaspiAuthenticatorprocesses. The authentication checks set the twoThreadLocalvariables. A specific condition then causes the method to return early and skip theThreadLocalcleanup. Public advisories do not yet detail the exact trigger. -
Jetty returns the worker thread to its pool and marks it available for new work. The thread still carries the privileged user's authentication context in its
ThreadLocalstorage. -
A new incoming request, potentially from a completely different user or an attacker, is assigned to the contaminated thread. The
ThreadLocalvalues from the previous privileged session are now visible to this request's processing pipeline. -
The new request runs with the identity and access level of the previous privileged user, which is a privilege escalation. The attacker can execute actions, access resources, or retrieve data that should be restricted to the original user's session.
The attack needs no crafted exploit payload. An attacker only has to send requests to the server and let normal thread pool scheduling place one of them on a contaminated thread. In high-concurrency environments with significant request volume, the probability of thread reuse, and therefore of context inheritance, rises substantially. That puts production deployments under load at particular risk.
Scope of Impact
The vulnerability affects deployments where JaspiAuthenticator is actively configured. Organizations that use Jetty purely with its built-in authentication mechanisms, without the JASPI bridge, are not affected by this flaw. JASPI is a standard Jakarta EE authentication SPI, though, so its use is common in enterprise Java environments.
Affected Systems and Versions
As of this analysis (April 8, 2026), no public vulnerability database or vendor advisory has published the specific affected version ranges. The JaspiAuthenticator class is present in multiple Jetty release lines:
- Jetty 12.1.x (the
org.eclipse.jetty.ee11.security.jaspipackage, confirmed in the 12.1.8 API documentation) - Jetty 12.0.x (the
org.eclipse.jetty.ee10.security.jaspipackage, confirmed in the 12.0.33 and 12.0.34 API documentation) - Jetty 12.0.x (the
org.eclipse.jetty.ee9.security.jaspipackage, confirmed in the 12.0.34 API documentation)
Until the Eclipse Foundation publishes explicit version guidance, treat any Jetty deployment as potentially vulnerable if it has Jakarta Authentication (JASPI) bridging enabled and uses thread pooling, which is the default configuration. To determine exposure, scan your Software Bill of Materials for the jaspi packages listed above.
Vendor Security History
The Eclipse Foundation has a consistent track record of addressing security issues in Jetty. These recent vulnerabilities give context for the project's security posture:
| CVE | Severity | Description |
|---|---|---|
| CVE-2026-1605 | High (CVSS 7.5) | A Gzip request memory leak in the GzipHandler class causing JVM OutOfMemoryError crashes |
| CVE-2025-1948 | High | An HTTP/2 client forcing the server to allocate a humongous byte buffer, leading to denial of service |
| CVE-2024-6763 | Low | URI parsing issues with invalid authorities |
The project publishes security advisories on its GitHub advisories page and coordinates with the Eclipse Foundation's CVE assignment process. If historical patterns hold, a formal patch and detailed advisory for CVE-2026-5795 should follow within the vendor's standard disclosure timeline.
References
- GitHub Security Advisory GHSA-r7p8-xq5m-436c
- Eclipse GitLab CVE Assignment Issue 92
- Jetty Security Advisories (GitHub)
- JaspiAuthenticator API Documentation (Jetty 12.1.8)
- JaspiAuthenticator API Documentation (Jetty 12.0.33)
- The Eclipse Jetty Project
- Jetty (web server) on Wikipedia
- CVE-2026-1605 Detail (NVD)
- CVE-2025-1948 Detail (NVD)
- CVE-2024-6763 Detail (NVD)



