CVE-2026-107371 in Auth0.js
Summary
by MITRE • 10/15/2026
When the authorize() method is called with a maxAge parameter, the auth0.js library does not validate the auth_time claim in the resulting ID token against the requested maxAge value. As a result, an application may process an ID token that represents an authentication event older than the requested maximum age.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability described involves a critical flaw in the implementation of session management within the Auth0 JavaScript library, specifically affecting the behavior of the authorize method when utilized with the maxAge parameter. This parameter is designed to enforce strict security policies by requiring that the authentication event represented by an Identity Token be no older than a specified duration. The core technical failure lies in the absence of validation logic for the auth_time claim contained within the resulting ID token against this requested maximum age threshold. Consequently, the library fails to reject tokens where the time elapsed since the user's last successful authentication exceeds the configured limit, thereby allowing stale credentials to be processed as if they were current and valid.
From a technical perspective, the OpenID Connect specification mandates that relying parties validate the auth_time claim when maxAge is specified in an authorization request. This validation ensures that the identity provider confirms the user has recently authenticated, which serves as a defense against session hijacking and credential reuse attacks. By omitting this check, the library creates a discrepancy between the security policy intended by the application developer and the actual enforcement mechanism provided by the authentication service. The flaw effectively neutralizes one of the primary controls for maintaining high-assurance sessions in web applications that rely on short-lived or frequently re-authenticated tokens to protect sensitive operations.
The operational impact of this vulnerability is significant, particularly for applications handling sensitive data or performing privileged actions such as financial transactions, administrative changes, or access control modifications. An attacker who obtains a valid but older ID token could potentially use it to impersonate the user without needing to provide fresh credentials. This bypasses multi-factor authentication requirements if those were part of the initial login session that generated the stale token. Furthermore, this flaw undermines compliance with security standards such as OWASP Authentication Cheat Sheet guidelines and NIST SP 800-63B regarding authenticator assurance levels, which emphasize the importance of verifying recency of authentication for higher assurance contexts.
To mitigate this risk, developers must ensure they are using a patched version of the auth0.js library where the validation logic has been corrected to strictly enforce the maxAge constraint against the auth_time claim. In addition to updating dependencies, application-level defenses should be implemented by validating token timestamps on every sensitive request rather than relying solely on session cookies or initial authentication checks. Implementing short-lived access tokens combined with refresh token rotation can further reduce the window of opportunity for an attacker exploiting a stale ID token. Regular security audits and static code analysis tools configured to detect missing OIDC claim validations should also be employed to prevent similar oversights in future development cycles.