CVE-2026-5795: Eclipse Jetty Privilege Escalation Flaw

CVE-2026-5795 Overview

A privilege escalation vulnerability exists in Eclipse Jetty's JASPIAuthenticator class where improper handling of ThreadLocal variables can lead to broken access control. The JASPIAuthenticator initiates authentication checks that set two ThreadLocal variables. Under certain conditions, an early return from the authentication code path occurs without properly clearing these ThreadLocals. When a subsequent request reuses the same thread, it inherits the previous authentication context, potentially allowing unauthorized access to protected resources.

Critical Impact

This vulnerability enables privilege escalation through ThreadLocal variable leakage, allowing attackers to inherit authentication contexts from previous requests and gain unauthorized access to protected resources.

Affected Products

• Eclipse Jetty (versions with JASPIAuthenticator implementation)

Discovery Timeline

• 2026-04-08 - CVE-2026-5795 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-5795

Vulnerability Analysis

This vulnerability is classified under CWE-226 (Sensitive Information in Resource Not Removed Before Reuse). The core issue lies in the improper cleanup of ThreadLocal variables within Eclipse Jetty's JASPI (Java Authentication Service Provider Interface) authentication mechanism.

When the JASPIAuthenticator class performs authentication checks, it stores authentication state in two ThreadLocal variables. These variables maintain request-specific authentication context that should be isolated per request. However, the implementation contains code paths where error conditions or specific authentication states trigger an early return from the authentication logic before the ThreadLocal cleanup routines execute.

In Java servlet containers like Jetty, threads are typically pooled and reused across multiple requests for performance optimization. When a thread that processed an authenticated request (with elevated privileges) is subsequently assigned to handle a request from an unauthenticated or lower-privileged user, the lingering ThreadLocal values from the previous request become accessible. This thread reuse pattern, combined with the missing cleanup, creates a race condition where authentication state persists beyond its intended scope.

The attack requires network access and depends on specific timing conditions related to thread pool assignment, making reliable exploitation more complex but still feasible in high-traffic environments.

Root Cause

The root cause is the failure to implement proper cleanup of ThreadLocal variables in all code paths within the JASPIAuthenticator class. Specifically, certain conditional branches that handle edge cases during authentication checks return early without invoking the necessary ThreadLocal.remove() calls. This violates the principle of ensuring sensitive information is cleared from reusable resources (CWE-226) and creates a state persistence issue across request boundaries.

Attack Vector

The vulnerability is exploitable over the network without requiring user interaction or prior authentication. An attacker could exploit this by:

1. Identifying a Jetty server using JASPI authentication
2. Sending multiple requests designed to trigger the early-return code path in JASPIAuthenticator
3. Timing requests to coincide with thread pool recycling, attempting to inherit an authenticated session from a previous user's request
4. If successful, gaining access to resources or functionality that should require authentication

The attack complexity is elevated due to the dependency on thread pool timing, but in environments with consistent traffic patterns, exploitation becomes more predictable.

Detection Methods for CVE-2026-5795

Indicators of Compromise

• Unusual access patterns where unauthenticated requests successfully access protected resources
• Authentication logs showing inconsistent user identities for sequential requests from the same session
• Audit trail anomalies indicating privilege level mismatches between authentication events and resource access
• Unexpected session sharing or cross-user data exposure incidents

Detection Strategies

• Monitor authentication subsystem logs for requests that bypass expected authentication flows
• Implement application-level logging to track ThreadLocal state across request boundaries in development/staging environments
• Deploy web application firewall rules to detect unusual access patterns to authenticated endpoints
• Analyze Jetty server access logs for requests to protected resources lacking proper authentication headers

Monitoring Recommendations

• Enable verbose logging for the JASPIAuthenticator class to capture authentication state transitions
• Implement real-time alerting for authentication bypass attempts or privilege escalation events
• Regularly audit access logs for discrepancies between authenticated users and accessed resources
• Monitor thread pool metrics for unusual recycling patterns that could indicate exploitation attempts

How to Mitigate CVE-2026-5795

Immediate Actions Required

• Review and apply the latest Eclipse Jetty security patches addressing this vulnerability
• Audit existing JASPI authentication configurations for potential exposure
• Consider implementing additional authorization checks at the application layer as defense-in-depth
• Enable enhanced logging to detect potential exploitation attempts

Patch Information

Eclipse has acknowledged this vulnerability through their security advisory process. Administrators should consult the GitHub Security Advisory and the Eclipse GitLab CVE Assignment Issue for official patch information and affected version details. Apply the vendor-provided security updates as soon as they become available.

Workarounds

• If JASPI authentication is not required, consider using alternative authentication mechanisms available in Jetty
• Implement a custom servlet filter that explicitly clears authentication-related ThreadLocals after each request
• Configure the thread pool to minimize thread reuse duration where operationally feasible
• Deploy additional authorization checks at the application layer that do not rely solely on JASPI authentication state