CVE-2026-114615 in Authlib
Summary
by MITRE • 10/22/2026
Authlib is a Python library which builds OAuth and OpenID Connect servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks asymmetric-key markers only at byte zero while Authlib's PEM loaders accept leading whitespace, comments, or a byte-order mark. In deployments that use the documented mixed algorithm registry and already configure verification with PEM or certificate bytes containing such a prefix, an unauthenticated attacker who knows those same public-key bytes can use them as an HMAC secret and forge HS256 tokens with arbitrary identity or authorization claims. This is a bypass of the remediation for CVE-2024-37568. The module-level jwt object reaches OctKey.import_key() in authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to identify prefixed asymmetric key material. This issue is fixed in version 1.9.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within the Authlib Python library represents a critical flaw in cryptographic input validation that allows for algorithm confusion attacks and subsequent token forgery. Authlib serves as a foundational component for implementing OAuth2 and OpenID Connect protocols, handling the creation and verification of JSON Web Tokens (JWTs). The core issue resides in the OctKey.import_key() method, which is responsible for processing symmetric keys used in HMAC-based signing algorithms such as HS256. Between versions 1.3.1 and 1.9.0, this function exhibited insufficient validation logic when determining the type of cryptographic material provided by an application developer or system administrator. Specifically, the implementation relied solely on checking byte zero for asymmetric-key markers to distinguish between public keys intended for RSA or ECDSA algorithms and symmetric secrets intended for HMAC operations. This narrow check failed to account for common formatting variations found in PEM-encoded data, such as leading whitespace, comments, or a Byte Order Mark (BOM), which are technically valid according to standard PEM parsing rules but were not considered by the key type detection logic.
This technical deficiency creates a severe operational impact when deployments utilize Authlib's mixed algorithm registry feature alongside verification configurations that accept PEM-formatted public keys containing these prefixes. In such scenarios, an unauthenticated attacker who has knowledge of the application's public-key bytes can exploit this discrepancy to bypass security controls. By presenting a public key with leading whitespace or comments as if it were an HMAC secret during token verification, the attacker forces the library to misinterpret the asymmetric material as symmetric cryptographic material. Consequently, the system proceeds to use the public key for verifying signatures intended for HS256 tokens. Since the private key corresponding to that public key is often known or derivable in certain contexts, or if the attacker can manipulate the verification process further, they can forge JWTs with arbitrary identity and authorization claims. This effectively bypasses authentication mechanisms, allowing unauthorized access to protected resources by injecting forged tokens that appear valid under the misconfigured HMAC algorithm.
The vulnerability serves as a direct bypass for the remediation efforts associated with CVE-2024-37568, indicating a persistent weakness in how key material is classified and processed across different cryptographic contexts. From an industry standards perspective, this flaw aligns closely with CWE-190: Integer Overflow or Wraparound if interpreted through type coercion failures, but more accurately maps to CWE-772: Missing Release of Resource after Effective Lifetime or specifically CWE-345: Insufficient Verification of Data Authenticity in the context of algorithm confusion. In terms of attack vectors, this behavior is consistent with MITRE ATT&CK technique T1608: Supply Chain Compromise if exploited via library updates, but more directly relates to T1190: Exploit Public-Facing Application and specifically the sub-technique involving Algorithm Confusion attacks where an attacker tricks a system into using a weaker or incorrect cryptographic algorithm. The failure lies in not strictly enforcing that keys designated for asymmetric operations are never treated as symmetric secrets, regardless of formatting nuances.
To mitigate this vulnerability, organizations must immediately upgrade to Authlib version 1.9.0 or later, where the OctKey.import_key() function has been patched to correctly identify and reject PEM-encoded public keys with leading whitespace, comments, or BOMs when they are being processed in contexts expecting symmetric secrets. For applications that cannot update immediately due to dependency constraints, a temporary mitigation involves strictly validating input data before passing it to Authlib's key import functions. Developers should strip any non-essential characters such as spaces, newlines at the start of strings, or BOMs from PEM inputs prior to processing. Additionally, enforcing strict algorithm whitelisting in JWT verification configurations can reduce risk by ensuring that only expected algorithms are accepted for specific token types, thereby preventing the fallback behavior that leads to this confusion. Regular security audits focusing on cryptographic implementation details and adherence to RFC 7518 standards are essential to prevent similar misconfigurations in future deployments.