CVE-2026-114618 in Authlib
Summary
by MITRE • 10/23/2026
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.0, the default RFC 7523 JWTBearerGrant.get_audiences() returns an empty list, causing JWTBearerGrant.verify_claims() to require only that an aud claim exists without matching the current authorization server. An attacker holding a legitimate assertion for another service can present it to a server that shares the signing key and uses the default grant, obtaining an access token across a trust boundary. Implementations that override get_audiences() with the server's valid audience identifiers are not affected. This issue is fixed in version 1.9.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in Authlib prior to version 1.9.0 represents a critical flaw in the implementation of OAuth 2.0 JWT Bearer Grant flows, specifically affecting how audience validation is performed during token verification. Authlib serves as a foundational Python library for building OAuth and OpenID Connect servers, handling complex authentication protocols that rely heavily on JSON Web Tokens (JWT) issued under RFC 7523. The core technical flaw resides in the default implementation of the get_audiences method within the JWTBearerGrant class. In versions preceding 1.9.0, this method incorrectly returns an empty list rather than a list containing the specific audience identifiers that the authorization server is configured to accept. This deviation from expected behavior fundamentally alters the logic flow within the verify_claims function, which relies on the output of get_audiences to validate incoming JWT assertions.
When the get_audiences method returns an empty list, the subsequent verification logic in verify_claims fails to enforce strict audience matching against the current authorization server's identity. Instead, it only checks for the mere existence of an aud claim within the token payload. This creates a significant security gap where the system does not validate whether the intended recipient of the JWT matches the service receiving the request. Consequently, any validly signed JWT that contains an aud claim is considered authentic by this flawed verification process, regardless of who the actual target audience should be. This behavior violates the fundamental principle of audience restriction in OAuth 2.0 and OpenID Connect standards, which are designed to prevent tokens issued for one service from being accepted by another unrelated or semi-trusted service.
The operational impact of this vulnerability is severe due to its potential for cross-service token abuse. An attacker who possesses a legitimate JWT assertion intended for a different service can present it to an authorization server that shares the same signing key and utilizes the default grant implementation. Because the verification process does not check if the audience in the token matches the current server, the flawed system accepts the foreign token as valid. The attacker is then able to obtain an access token from this second server, effectively bypassing trust boundaries between services. This scenario allows for unauthorized access to resources protected by the vulnerable authorization server using credentials that were never intended for it, leading to potential data breaches and privilege escalation across interconnected systems relying on shared signing infrastructure.
This issue aligns with CWE-287, which describes Improper Authentication, as well as CWE-345, Insufficient Verification of Data Authenticity, since the system fails to properly verify that the token's intended audience matches its actual recipient. From an ATT&CK perspective, this vulnerability facilitates lateral movement and privilege escalation by allowing attackers to leverage stolen or forged tokens across service boundaries, exploiting trust relationships established through shared cryptographic keys. It is important to note that implementations which explicitly override the get_audiences method to return their specific valid audience identifiers are not affected by this flaw, as they bypass the default logic entirely. To mitigate this risk, organizations must upgrade Authlib to version 1.9.0 or later, where the default behavior has been corrected to properly enforce audience validation. For those unable to immediately update, manually overriding the get_audiences method in custom implementations is a necessary interim control to ensure that tokens are only accepted when their audience claim matches the server's expected identifiers.