CVE-2026-114617 in Authlib
Summary
by MITRE • 10/22/2026
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.0, OpenIDMixin.parse_id_token() reads the nonce_supported decision from the untrusted ID token being validated and sets the expected nonce to null when that claim is the JSON boolean false. In implicit and hybrid relying parties, or applications that directly accept externally supplied ID tokens, an attacker with a captured validly signed token can bypass the nonce-to-session binding and replay the victim's token into an attacker-controlled session. Plain authorization code flow is not affected, and the token must still pass signature, issuer, and audience validation. OpenIDMixin.parse_id_token() trusts nonce_supported in both authlib/integrations/base_client/sync_openid.py and authlib/integrations/base_client/async_openid.py to disable the expected nonce. This issue is fixed in version 1.9.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within Authlib, a widely used Python library for implementing OAuth2 and OpenID Connect servers, represents a critical flaw in how identity tokens are validated during authentication flows. Specifically located in the OpenIDMixin.parse_id_token() method across both synchronous and asynchronous integration modules, this issue stems from an insecure trust relationship between the server's validation logic and untrusted input data. The core technical failure occurs when the library processes the nonce_supported claim contained within an incoming ID token. Instead of relying on a pre-configured or static policy defined by the application developer to determine whether nonces are required for security, Authlib dynamically reads this decision from the ID token itself. If the attacker-controlled token contains the JSON boolean value false for the nonce_supported claim, the library sets the expected nonce to null, effectively disabling nonce validation for that specific authentication transaction.
This design flaw creates a significant bypass mechanism in implicit and hybrid authorization flows, as well as in any application architecture that directly accepts externally supplied ID tokens without strict server-side policy enforcement. In these scenarios, an attacker who has captured a validly signed token from a victim can manipulate the session binding process. By presenting this token to the authentication endpoint, the attacker forces the library to skip nonce verification due to the manipulated claim. Consequently, the cryptographic link between the specific authorization request and the resulting session is severed. This allows the replayed token to be accepted as valid within an attacker-controlled context rather than being tied exclusively to the original victim's session state.
The operational impact of this vulnerability is severe in environments where implicit or hybrid flows are employed for client-side applications or single-page applications that handle tokens directly. An adversary can exploit this by capturing a legitimate ID token, potentially through cross-site scripting attacks or other means of intercepting browser-based traffic, and then replaying it to establish unauthorized access under their own session parameters. This undermines the fundamental security guarantee provided by nonces in OpenID Connect, which is to prevent authorization code injection and replay attacks by ensuring that tokens are bound to specific authentication requests initiated by legitimate users. Although plain authorization code flow remains unaffected because it relies on server-to-server exchanges where nonce validation logic may differ or be less susceptible to this specific client-side manipulation vector, the risk to direct token acceptance workflows is substantial.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution is to upgrade Authlib to version 1.9.0 or later, which corrects the parsing logic to no longer trust the nonce_supported claim from untrusted sources for disabling security checks. For applications unable to immediately update their dependencies, developers should implement custom validation layers that enforce strict server-side policies regarding nonces regardless of what is contained in the ID token claims. It is essential to ensure that nonce verification remains mandatory for all implicit and hybrid flows unless explicitly disabled by configuration rather than by content within the token itself. Additionally, organizations should review their reliance on client-side token handling and consider migrating to more secure authorization code flow with PKCE where possible to reduce exposure to such replay attacks.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately validate input data before using it in security-critical decisions. It also relates to CWE-345 Insufficient Verification of Data Authenticity because the system trusts information from an untrusted source (the ID token) for a critical security control. In terms of offensive tactics, this flaw facilitates MITM: Session Hijacking and Mitm: Token Replay within the ATT&CK framework, allowing attackers to maintain persistent access by reusing stolen credentials or tokens in unauthorized contexts. The severity is heightened by the fact that it requires only a captured valid token, which may be obtained through common web vulnerabilities like XSS, making it an attractive target for automated exploitation campaigns targeting Python-based identity providers and clients.