CVE-2026-5795

In Eclipse Jetty, the class JASPIAuthenticator initiates the authentication checks, which set two ThreadLocal variable.

Upon returning from the initial checks, there are conditions that cause an early return from the JASPIAuthenticator code without clearing those ThreadLocals.

A subsequent request using the same thread inherits the ThreadLocal values, leading to a broken access control and privilege escalation.

Vulnerability Details

FieldValueCVE IDCVE-2026-5795PROJECT AFFECTEDGitlabVERSIONS AFFECTEDunknownFIXED INunknown~ FIX DATEunknownSEVERITYHIGHCATEGORYCWE-226 - CWE-226, CWE-287 - Improper Authentication

Overview

In Eclipse Jetty, the class JASPIAuthenticator initiates the authentication checks, which set two ThreadLocal variable.

Upon returning from the initial checks, there are conditions that cause an early return from the JASPIAuthenticator code without clearing those ThreadLocals.

A subsequent request using the same thread inherits the ThreadLocal values, leading to a broken access control and privilege escalation.

Details

Module Info

• Product: Jetty
• Affected packages: jetty.project
• Affected versions: >= 9.4.0 < 9.4.61, >= 10.0.0 < 10.0.29, >= 11.0.0 < 11.0.29, >= 12.0.0 < 12.0.34, >= 12.1.0 < 12.1.8
• GitHub repository: https://github.com/jetty/jetty.project
• Package manager: Maven
• Fixed In: 9.4.61, 10.0.29, 11.0.29, 12.0.34, 12.1.8

Mitigation

• Upgrade to the fixed version of Eclipse Jetty as soon as it becomes available to address the vulnerability in JASPIAuthenticator.
• Implement a custom authentication filter that explicitly clears ThreadLocal variables after each request to prevent inheritance of values across requests.
• Review and restrict access controls to sensitive endpoints, ensuring that only authorized roles can access critical resources.
• Utilize a reverse proxy or API gateway to enforce additional authentication checks and request validation before reaching the Jetty server.
• Conduct a thorough audit of the application’s threading model to identify and mitigate any other potential ThreadLocal misuse scenarios.

Steps To Reproduce

1. Set Up Affected Environment: Deploy Eclipse Jetty version 9.4.0 to 9.4.60 (or any affected version) on a server with Java 8 or higher. Ensure that the JASPIAuthenticator is configured for authentication in your web application.
2. Configure Authentication: In your web application, configure a JASPI-based authentication mechanism that utilizes the JASPIAuthenticator. Ensure that at least two different user roles are defined for testing purposes.
3. Initiate Authentication Check: Send an initial authentication request to the server using valid credentials for the first user role. Monitor the server logs to confirm that the JASPIAuthenticator processes the request without errors.
4. Trigger Early Return: Simulate a condition that causes the JASPIAuthenticator to return early without clearing the ThreadLocal variables. This can be done by implementing a custom authentication module that fails to complete the authentication process under specific conditions (e.g., a missing attribute).
5. Send Subsequent Request: While the thread from the previous request is still active, send a new request using valid credentials for a different user role. Ensure that this request is processed by the same thread that handled the initial request.
6. Verify Access Control: Observe the response from the server for the second request. If the response indicates that the second user role has access to resources or actions that should be restricted, this confirms the vulnerability.
7. Post-Remediation Verification: After applying a patch or implementing a fix, repeat steps 3 to 6. Confirm that the ThreadLocal variables are cleared appropriately after each request, and that the second request is denied access as expected, ensuring proper access control is enforced.