CVE-2023-41900 Overview
CVE-2023-41900 is a weak authentication vulnerability affecting Eclipse Jetty, a widely-used Java-based web server and servlet engine. The vulnerability exists in the OpenIdAuthenticator component when configured with an optional nested LoginService. When the LoginService revokes an already authenticated user, the current request continues to treat the user as authenticated, potentially allowing unauthorized access to protected resources.
Critical Impact
Authenticated users whose credentials have been revoked may still access protected resources for the duration of the current request, bypassing authentication controls that should have blocked access.
Affected Products
- Eclipse Jetty versions 9.4.21 through 9.4.51
- Eclipse Jetty version 10.0.15
- Eclipse Jetty version 11.0.15
- Debian Linux 11.0
- Debian Linux 12.0
Discovery Timeline
- 2023-09-15 - CVE CVE-2023-41900 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2023-41900
Vulnerability Analysis
This vulnerability is classified under CWE-287 (Improper Authentication) and CWE-1390 (Weak Authentication). The flaw resides in how Eclipse Jetty's OpenIdAuthenticator handles authentication state when integrated with a nested LoginService. The authentication check timing creates a window where revoked credentials remain valid for an in-flight request.
The vulnerability requires network access and low-privilege authenticated access to exploit. When a LoginService determines that a previously authenticated user should be rejected (such as credential revocation, account lockout, or permission changes), the authentication decision is not immediately enforced on the current request. Instead, the authentication is only cleared from the session after the current request completes, meaning subsequent requests will correctly deny access, but the problematic request proceeds with authenticated privileges.
Root Cause
The root cause stems from improper synchronization between the authentication state check and the LoginService revocation decision. When the OpenIdAuthenticator validates a user with a nested LoginService, the order of operations fails to immediately invalidate the authentication context for the current request. The session cleanup occurs after request processing, creating a race condition where the revoked user's request executes with elevated privileges.
This affects only configurations where:
- The jetty-openid module is in use
- A nested LoginService is configured within the OpenIdAuthenticator
- The LoginService has logic to reject previously authenticated users
Attack Vector
The attack vector is network-based, requiring an attacker to have initially authenticated through the OpenID mechanism. To exploit this vulnerability, an attacker would need to:
- Obtain valid authentication through the OpenID flow
- Trigger an action that causes the LoginService to revoke their authentication (or time the attack with an administrative revocation)
- Submit a request during the revocation window before the session is cleared
- Access protected resources despite credential revocation
The vulnerability mechanism involves authentication state persistence where the session remains valid for the current HTTP request even after the LoginService has determined the user should be rejected. This is a subtle timing issue that affects the immediate enforcement of authentication decisions.
Detection Methods for CVE-2023-41900
Indicators of Compromise
- Unusual access patterns where users access resources immediately after account status changes
- Log entries showing successful authentication followed by immediate revocation for the same session
- Access to protected endpoints by users whose credentials were recently revoked in identity provider systems
Detection Strategies
- Monitor Jetty access logs for requests from users whose sessions were invalidated during the same time window
- Implement audit logging on the LoginService to track revocation events and correlate with subsequent access attempts
- Review application logs for authentication state inconsistencies between the OpenID provider and local LoginService decisions
Monitoring Recommendations
- Enable detailed authentication logging in Jetty's OpenIdAuthenticator component
- Set up alerts for access patterns where revoked users complete requests successfully
- Monitor for discrepancies between OpenID provider session state and local authentication state
How to Mitigate CVE-2023-41900
Immediate Actions Required
- Upgrade Eclipse Jetty to version 9.4.52, 10.0.16, or 11.0.16 or later immediately
- Review current Jetty configurations to identify deployments using OpenIdAuthenticator with nested LoginService
- Consider temporarily disabling nested LoginService configurations until patches can be applied
- Audit access logs for any potential exploitation attempts
Patch Information
Eclipse has released patched versions addressing this vulnerability. The fixes are available in:
- Jetty 9.4.52 for the 9.x branch
- Jetty 10.0.16 for the 10.x branch
- Jetty 11.0.16 for the 11.x branch
Patch details can be found in GitHub Pull Request #9528 and GitHub Pull Request #9660. The official security advisory is documented in GitHub Security Advisory GHSA-pwh8-58vv-vw48.
Debian users should apply Debian Security Advisory DSA-5507 for their respective distributions.
Workarounds
- Remove the nested LoginService from OpenIdAuthenticator configurations if not strictly required
- Implement additional authorization checks at the application layer independent of the LoginService revocation
- Add request-level authentication validation in filters or interceptors that execute before protected resource access
- Consider implementing session termination at the load balancer or reverse proxy level for revoked users
# Configuration example - Upgrading Jetty via Maven
# Update pom.xml dependency to patched version:
# <dependency>
# <groupId>org.eclipse.jetty</groupId>
# <artifactId>jetty-openid</artifactId>
# <version>11.0.16</version>
# </dependency>
# Verify installed Jetty version
java -jar $JETTY_HOME/start.jar --version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

