CVE-2026-5795: Jetty Authentication Bypass and Privilege Escalation (JASPIAuthenticator)
How Uncleared ThreadLocal Variables in Jetty's JASPIAuthenticator Enable Authentication Bypass and Cross-User Privilege Escalation
A flaw in Jetty’s authentication layer can allow one user’s privileges to be applied to another user’s request, effectively bypassing access controls.
CVE-2026-5795 stems from improper handling of ThreadLocal variables in Jetty’s JASPIAuthenticator. Under certain early-return authentication paths, these variables are not cleared. Because Jetty reuses threads across requests, a subsequent request may inherit stale authentication context from a prior user.
The result is authentication bypass and privilege escalation — a direct violation of access control guarantees.
Why this matters
This is not a typical application-layer bug; it impacts the authentication boundary itself.
This vulnerability affects the authentication boundary itself, which is a foundational control in frameworks like SOC 2, PCI DSS, HIPAA, and FedRAMP. Findings that undermine authentication are treated as tier-one security issues, regardless of CVSS complexity scoring.
Although CVE-2026-5795 is rated CVSS 7.4 (High), vulnerabilities that enable privilege escalation across users are often prioritized as critical in practice.
TL;DR
Who is affected
This vulnerability has two preconditions. Both must be true for your deployment to be exposed.
Precondition 1: Affected version. Any Jetty version in these ranges:
Precondition 2: JASPIAuthenticator in use. This vulnerability only applies to deployments using JASPIC (Jakarta Authentication SPI for Containers).
JASPI is not Jetty’s default authentication mechanism. Standard authentication methods (form-based, basic, digest, certificate) are not affected.
To confirm exposure:
- Search for org.eclipse.jetty.security.jaspi or JASPIAuthenticator in your configuration
- If not present, your deployment is unlikely to be affected by this specific vulnerability
What the vulnerability actually does
This vulnerability affects how authentication is handled in Jetty when using JASPIC. Under certain conditions, Jetty can unintentionally retain authentication data between requests, creating a path for authentication bypass and privilege escalation.
Jetty processes requests using a pool of reusable threads. During authentication, user context is temporarily stored as part of the request handling process. However, in certain failure or early-exit scenarios, that authentication state is not properly cleared before the thread is returned to the pool.
Because those threads are reused, the next request handled by the same thread can inherit leftover authentication data.
For example, if an administrator’s request is processed and the authentication context is not cleared, a subsequent request handled by that same thread could execute with administrative privileges without re-authenticating.
The result is a true privilege escalation scenario: one user can inherit the permissions of another, including elevated or administrative access. This directly impacts both data confidentiality and system integrity.
While exploitation requires specific conditions, those conditions are realistic in production environments with high traffic and frequent thread reuse.
Why this matters operationally
This vulnerability impacts the authentication layer itself, meaning it undermines the foundation of access control across your application.
Authentication is a core control in frameworks like SOC 2, PCI DSS, HIPAA, and FedRAMP. When authentication can be bypassed or manipulated, it directly calls into question whether access controls are functioning as intended. Authentication bypass is considered a high-severity, audit-critical finding in enterprise environments, particularly in systems relying on container-managed authentication.
This vulnerability was publicly disclosed before a coordinated fix was fully released, extending the exposure window. Attackers monitoring CVE disclosures have had additional time to analyze and potentially exploit the issue.
Jetty 9.4.x, 10.0.x, and 11.0.x are all end-of-life and no longer receive ongoing security support. While version 9.4.61 includes a fix for this specific vulnerability, there is no maintained patch stream for future vulnerabilities. Organizations running 9.4.x, 10.0.x, and 11.0.x are operating without a sustainable remediation path as new CVEs continue to emerge.
Technical detail
Root cause: JASPIAuthenticator sets two ThreadLocal variables when initiating authentication checks. Certain early return paths in the authentication flow exit without calling the cleanup code that clears those ThreadLocals. Java's thread pool model means these stale values persist on the thread until another request overwrites them or cleanup is explicitly called.
Vulnerability class: CWE-226 (Sensitive Information in Resource Not Removed Before Reuse) and CWE-287 (Improper Authentication).
Affected component: org.eclipse.jetty.security.jaspi.JASPIAuthenticator in jetty-jaspi module
CVSS 3.1 vector breakdown: - AV:N (network-accessible: any inbound request can trigger this) - AC:H (high complexity: requires thread reuse timing and JASPIC early-return code path) - PR:N (no privileges required to send the triggering request) - UI:N (no user interaction required) - C:H / I:H (full confidentiality and integrity impact via auth context inheritance) - A:N (no availability impact)
https://nvd.nist.gov/vuln/detail/CVE-2026-5795
Remediation
If you are on a supported Jetty version
Upgrade to the latest patched version for your branch: 12.0.34, or 12.1.8. For supported versions, this is the recommended and standard remediation path.
If you are running Jetty 9.4.x or 10.0.x or 11.0.x
Jetty 9.4.x, 10.0.x, 11.0.x are end-of-life and no longer receive ongoing OSS security updates. While version 9.4.61 includes a fix for this specific vulnerability, it is not part of a maintained release stream. Upgrading to Jetty 12.0 or 12.1 are the correct long-term path for continued security and support.
If migration is not feasible on your current timeline, HeroDevs NES for Jetty provides a maintained, security-patched distribution of Jetty 9, 10, and 11. This enables you to remediate CVE-2026-5795 and future vulnerabilities without requiring an immediate major version upgrade.
Contact HeroDevs to learn about NES for Jetty
NES provides a bridge to a supported future without leaving your environment exposed today.
Frequently asked questions about CVE-2026-5795
Does this affect all Jetty deployments?
No. Only deployments using JASPIAuthenticator for authentication are affected. Standard Jetty authentication mechanisms (form-based, basic, client certificate) are not impacted. Check your configuration for org.eclipse.jetty.security.jaspi references to confirm.
What is JASPIC and do I use it?
JASPIC (Jakarta Authentication SPI for Containers) is a pluggable authentication framework used in Jakarta EE container-managed auth scenarios. If you are running a Jakarta EE application server with container-managed security, you may be using it. If you are running Jetty standalone with application-managed authentication, you likely are not. Search your deployment configuration to confirm.
Which versions are affected?
Jetty 9.4.0 through 9.4.60, 10.0.0 through 10.0.28, 11.0.0 through 11.0.27
I’m on an affected Jetty version. Is upgrading within my branch sufficient?
Upgrading to the fixed version within your current branch resolves CVE-2026-5795 for that release line. This includes the following NES versions:
- Jetty 9.4.61
- Jetty 10.0.28
- Jetty 11.0.28
However, the long-term implications differ by branch.
These versions are end-of-life and no longer receive ongoing OSS security updates.
The long-term path is to upgrade the latest OSS version, such as Jetty 12, which continues to receive open-source features and security updates.
Does this affect Jetty as a transitive dependency?
Yes. Many frameworks embed Jetty or pull it in as a transitive dependency (Spring Boot's embedded server, Eclipse IDE, Jenkins, and others). Run your SCA tool against your full dependency tree to identify any embedded Jetty versions in the affected ranges.
Taking action
If you are using JASPIAuthenticator on an affected Jetty version, this represents an active authentication bypass risk that should be addressed immediately.
For teams running Jetty 9.4.x, this vulnerability highlights a broader issue: CVE-2026-5795 will not be the last vulnerability without a maintained OSS patch path. The correct long-term move is migrating to a supported Jetty version.
If that migration is not feasible on your current timeline, HeroDevs NES for Jetty provides a supported path to remain secure and compliant. NES closes current CVE exposure, including CVE-2026-5795, while giving your team time to plan and execute a proper upgrade.
Contact HeroDevs to learn about NES for Jetty
Related vulnerabilities:
.png)
