Introduction
A flaw in Eclipse Jetty's Jakarta Authentication (JASPI) integration allows one user's authentication context to silently leak to another user's request through uncleared ThreadLocal variables in pooled threads. For any organization running Jetty with JASPI enabled, this means that under normal production concurrency, a request can inherit the identity and privileges of a completely unrelated prior user, resulting in privilege escalation without any 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, WebSocket, and is embedded in major products including Apache ActiveMQ, Apache Maven, Apache Spark, Google App Engine, and Hadoop. Its broad adoption as both a standalone server and an embedded component means vulnerabilities in Jetty frequently have a large transitive blast radius across the enterprise software ecosystem.
Technical Information
Root Cause: ThreadLocal State Leakage in JaspiAuthenticator
The vulnerability, tracked as CVE-2026-5795 with a CVSS score of 7.4, is rooted in the JaspiAuthenticator class. This class acts as the bridge between Jakarta Authentication (JASPI) and Jetty's internal security framework. It is present in multiple Jetty API versions, including the org.eclipse.jetty.ee11.security.jaspi and org.eclipse.jetty.ee10.security.jaspi packages.
During the authentication lifecycle, JaspiAuthenticator initiates authentication checks that populate two ThreadLocal variables with the current request's authentication state. ThreadLocal storage in Java is scoped to the executing thread; any data stored there persists for the lifetime of that thread unless explicitly removed.
The defect occurs when certain conditions trigger an early return from the JaspiAuthenticator code path. Under these early return conditions, the cleanup logic that would normally clear the two ThreadLocal variables is bypassed entirely. The authentication state from the current user's request remains attached to the thread.
This 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, retains sensitive authentication data after the request that created it has completed.
- CWE-287 (Improper Authentication): The subsequent request operating on the contaminated thread is treated as authenticated under the wrong identity, bypassing proper authentication verification.
Attack Flow
Production Jetty deployments use thread pooling for performance. A finite set of worker threads handles incoming requests, and threads are recycled after each request completes. This is standard behavior and is fundamental to how Jetty achieves its scalability.
The exploitation sequence proceeds as follows:
-
Privileged user triggers the early return condition. A legitimate user with elevated privileges sends a request that is processed by
JaspiAuthenticator. The authentication checks set the twoThreadLocalvariables. A specific condition (the exact trigger is not yet detailed in public advisories) causes the method to return early, skipping theThreadLocalcleanup. -
Thread returns to the pool contaminated. The worker thread, still carrying the privileged user's authentication context in its
ThreadLocalstorage, is returned to Jetty's thread pool and marked as available for new work. -
Subsequent request inherits the context. 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. -
Privilege escalation occurs. The new request operates under the identity and access level of the previous privileged user. The attacker can execute actions, access resources, or retrieve data that should be restricted to the original user's session.
Notably, this attack does not require a crafted exploit payload. The attacker simply needs to send requests to the server and, through normal thread pool scheduling, land on a contaminated thread. In high concurrency environments with significant request volume, the probability of thread reuse (and therefore context inheritance) increases substantially. This makes the vulnerability particularly relevant for production deployments under load.
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 specific flaw. However, given that JASPI is a standard Jakarta EE authentication SPI, its use is common in enterprise Java environments.
Affected Systems and Versions
At the time of this analysis (April 8, 2026), the specific affected version ranges have not been published in public vulnerability databases or vendor advisories. The JaspiAuthenticator class is present across 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)
Any Jetty deployment that has Jakarta Authentication (JASPI) bridging enabled and uses thread pooling (the default configuration) should be considered potentially vulnerable until the Eclipse Foundation publishes explicit version guidance. Organizations should scan their Software Bill of Materials for the jaspi packages listed above to determine exposure.
Vendor Security History
The Eclipse Foundation maintains a consistent track record of addressing security issues in Jetty. Recent high severity vulnerabilities provide 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 actively publishes security advisories through its GitHub advisories page and coordinates with the Eclipse Foundation's CVE assignment process. Based on historical patterns, 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)
