CVE-2026-114615

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.

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.

Summary

OctKey.import_key() carries the only guard that stops an asymmetric public key from being used as an HMAC secret in authlib.jose. That guard is raw_key.startswith(POSSIBLE_UNSAFE_KEYS) — anchored at byte 0 — while the loader that consumes the identical bytes on the asymmetric path (cryptography.hazmat.primitives.serialization.load_pem_public_key / load_pem_x509_certificate) skips anything before the -----BEGIN line. A PEM public key or X.509 certificate carrying one leading byte — a newline, a space, four spaces of indentation, a UTF-8 BOM, or a comment line — is therefore not recognised, falls through, and becomes the HMAC secret. An attacker holding only the issuer's public key then mints an HS256 token with arbitrary claims that jwt.decode() accepts as authentic.

This is an incomplete fix of CVE-2024-37568 / GHSA-5357-c2jx-v7qh. That advisory's fix is exactly this guard (git log -S 'POSSIBLE_UNSAFE_KEYS' -- authlib/jose/rfc7518/oct_key.py returns a single commit, 3bea812 "fix: prevent OctKey to import ssh/rsa/pem keys", referencing issue #654), and the original attack works again unchanged whenever the stored PEM does not start at offset 0.

Reproduced end-to-end on 1.8.0, the newest release (published 2026-08-30), and on origin/main (c529a61), with cryptography 50.0.2.

Preconditions

Both are deployment properties; neither is attacker-controlled at request time, and the attacker needs no secret and no user interaction.

1. The relying party uses the documented module-level jwt object. from authlib.jose import jwt is built at authlib/jose/__init__.py:55-72 with the full list ["HS256","HS384","HS512","RS256",...,"EdDSA"], and JsonWebToken.decode (authlib/jose/rfc7519/jwt.py:80) exposes no algorithms parameter, so a caller of the documented object has no way to narrow it. This is the first code sample in docs/jose/jwt.rst:21-31.

   This hazard is already documented: docs/jose/jwt.rst:73-79 says "This decoding method is insecure. By default jwt.decode parses the alg header. This allows symmetric macs and asymmetric signatures.", and docs/jose/jwt.rst:94-98 says "You should never combine symmetric (HS) and asymmetric (RS, ES, PS) signature schemes." The point of this report is not that the mixed list exists — it is that the oct_key.py:81 backstop shipped for precisely that documented hazard does not hold.

2. The verification key is passed as PEM/certificate text whose bytes do not begin at offset 0 with -----BEGIN . Each of the following forms was confirmed to forge, and each also still verifies a genuine RS256/ES256 token with the identical bytes, so nothing in the deployment looks broken:

   • one leading newline — what a triple-quoted Python literal produces
   • one leading space
   • four-space indentation — an indented YAML/JSON/TOML config block
   • a UTF-8 BOM — a Windows-editor artifact
   • a leading comment line
   • all of the above applied to an X.509 CERTIFICATE PEM instead of a PUBLIC KEY PEM

   A raw DER SPKI blob also bypasses the guard, but DER cannot be used for genuine asymmetric verification through this path, so I exclude it as a non-deployable configuration and mention it only as further evidence of the recogniser/loader gap.

Details

authlib/jose/rfc7518/oct_key.py:10-17

POSSIBLE_UNSAFE_KEYS = (
    b"-----BEGIN ",
    b"---- BEGIN ",
    b"ssh-rsa ",
    b"ssh-dss ",
    b"ssh-ed25519 ",
    b"ecdsa-sha2-",
)

authlib/jose/rfc7518/oct_key.py:78-84

raw_key = to_bytes(raw)

# security check
if raw_key.startswith(POSSIBLE_UNSAFE_KEYS):
    raise ValueError("This key may not be safe to import")

key = cls(raw_key=raw_key, options=options)

bytes.startswith is anchored. The loader on the asymmetric path is not: authlib/jose/rfc7517/_cryptography_key.py:22-29 calls load_pem_public_key /…

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.

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.

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.