CVE-2026-27962: Authlib Auth Bypass Vulnerability

CVE-2026-27962 Overview

CVE-2026-27962 is a critical JWK Header Injection vulnerability in Authlib, a widely-used Python library for building OAuth and OpenID Connect servers. This authentication bypass vulnerability allows unauthenticated attackers to forge arbitrary JWT tokens that pass signature verification, effectively bypassing authentication and authorization mechanisms entirely.

The vulnerability exists in Authlib's JWS (JSON Web Signature) implementation prior to version 1.6.9. When key=None is passed to any JWS deserialization function, the library extracts and uses the cryptographic key embedded in the attacker-controlled JWT jwk header field. This allows an attacker to sign a token with their own private key, embed the matching public key in the header, and have the server accept the forged token as cryptographically valid.

Critical Impact

Unauthenticated attackers can forge arbitrary JWT tokens to bypass authentication and authorization, gaining unauthorized access to protected resources and impersonating any user.

Affected Products

• Authlib versions prior to 1.6.9
• Applications using Authlib's JWS deserialization functions with key=None
• OAuth and OpenID Connect servers built with vulnerable Authlib versions

Discovery Timeline

• 2026-03-16 - CVE-2026-27962 published to NVD
• 2026-03-17 - Last updated in NVD database

Technical Details for CVE-2026-27962

Vulnerability Analysis

This vulnerability falls under CWE-347 (Improper Verification of Cryptographic Signature). The core issue lies in how Authlib's JWS implementation handles key resolution during token verification. When no explicit key is provided (i.e., key=None), the library automatically extracts and trusts the jwk (JSON Web Key) embedded in the JWT header itself.

This design flaw fundamentally breaks the security model of JWT signature verification. The cryptographic signature on a JWT is only meaningful when verified against a pre-trusted key. By allowing the key to be supplied within the token itself, an attacker controls both the data being signed and the key used to verify that signature—rendering the verification meaningless.

Root Cause

The root cause is the automatic extraction and use of the jwk header field when no key is explicitly provided. In the vulnerable code path, when key is None and a jwk field exists in the header, the library assigns header["jwk"] as the verification key. This allows attacker-controlled input to determine the cryptographic key used for signature verification, completely undermining the authentication mechanism.

Attack Vector

An attacker can exploit this vulnerability through the following attack flow:

1. Generate an attacker-controlled RSA or EC key pair
2. Craft a malicious JWT with arbitrary claims (e.g., elevated privileges, impersonated user identity)
3. Sign the token using the attacker's private key
4. Embed the attacker's public key in the JWT's jwk header field
5. Submit the forged token to the vulnerable application
6. The server verifies the signature using the attacker-supplied public key and accepts the token as valid

The vulnerable code automatically extracted the jwk from the header when no key was provided:

# Vulnerable code in authlib/jose/rfc7515/jws.py (before patch)
        algorithm = self.ALGORITHMS_REGISTRY[alg]
        if callable(key):
            key = key(header, payload)
-       elif key is None and "jwk" in header:
-           key = header["jwk"]
        key = algorithm.prepare_key(key)
        return algorithm, key

Source: GitHub Commit

The same pattern existed in the JWE implementation:

# Vulnerable code in authlib/jose/rfc7516/jwe.py (before patch)
def prepare_key(alg, header, key):
    if callable(key):
        key = key(header, None)
-   elif key is None and "jwk" in header:
-       key = header["jwk"]
    return alg.prepare_key(key)

Source: GitHub Commit

Detection Methods for CVE-2026-27962

Indicators of Compromise

• JWT tokens containing embedded jwk header fields in authentication requests
• Unusual authentication success patterns for users or sessions that should not have access
• JWT tokens with public keys that do not match the server's configured signing keys
• Authentication logs showing successful validation of tokens with unrecognized key material

Detection Strategies

• Monitor for JWT tokens containing jwk header fields in authentication endpoints
• Implement logging to capture and alert on tokens that include embedded key material
• Review application code for instances where JWS/JWE deserialization is called with key=None
• Deploy dependency scanning tools to identify vulnerable Authlib versions in your environment

Monitoring Recommendations

• Enable detailed logging for all JWT validation operations including header contents
• Set up alerts for authentication anomalies that may indicate token forgery
• Monitor package management systems for outdated Authlib dependencies
• Implement token introspection logging to detect unusual claim patterns

How to Mitigate CVE-2026-27962

Immediate Actions Required

• Upgrade Authlib to version 1.6.9 or later immediately
• Audit all code paths that use JWS/JWE deserialization to ensure explicit keys are always provided
• Review authentication logs for evidence of exploitation using embedded jwk headers
• Invalidate and rotate any existing tokens that may have been issued during the vulnerable period

Patch Information

The vulnerability has been patched in Authlib version 1.6.9. The fix removes the automatic extraction and use of the jwk header field when key=None is passed to deserialization functions. After the patch, applications must always provide an explicit key for signature verification.

Upgrade using pip:

pip install --upgrade authlib>=1.6.9

For additional details, refer to the GitHub Security Advisory GHSA-wvwj-cvrp-7pv5 and the patched release v1.6.9.

Workarounds

• Always provide an explicit key parameter when calling JWS/JWE deserialization functions—never pass key=None
• Implement additional validation logic to reject any JWT tokens containing jwk header fields
• Use a key lookup callback function that ignores the header's jwk field and retrieves keys from a trusted source only
• Consider implementing token structure validation at the application layer to reject tokens with unexpected headers

# Verify installed Authlib version and upgrade if vulnerable
pip show authlib | grep Version
pip install --upgrade 'authlib>=1.6.9'

# Confirm upgrade was successful
pip show authlib | grep Version