CVE-2026-29000: bypass de autenticação JWT no pac4j por validação inadequada de algoritmo

A CVE-2026-29000 afeta o JwtAuthenticator do pac4j-jwt, componente que costuma ficar na fronteira de confiança da aplicação (gateway, borda de API ou camada de autenticação web). Em ambientes Java, esse ponto valida assinatura, emissor, audiência e expiração antes de materializar o perfil autenticado.

O defeito ocorre na validação de assinatura quando há combinação inadequada entre algoritmo declarado no JWT e chave usada no verificador. Na prática, isso abre espaço para aceitar token forjado em cenários de configuração permissiva, resultando em bypass de autenticação.

Resumo executivo e impacto

Em arquiteturas que usam JWT Bearer para sessão de usuário ou comunicação entre serviços, a falha pode permitir aceitação de credenciais não autênticas. Se o token carregar claims de privilégio elevado, o atacante pode atingir rotas administrativas sem conhecer credenciais válidas.

O impacto tende a ser transversal: autenticação, autorização e auditoria. Em arquiteturas com SSO, API Gateway e microserviços, um token indevido aceito no ponto de entrada pode ser propagado internamente e ampliar o raio de comprometimento.

• Risco de personificação de identidade (account spoofing).
• Possível escalada de privilégio via claims administrativas.
• Acesso indevido a APIs internas protegidas por bearer token.
• Quebra de rastreabilidade de auditoria por sessões não legítimas.

Causa raiz técnica

O cenário descrito publicamente é de algorithm confusion: o verificador processa o JWT com premissas diferentes da política criptográfica esperada. Em termos práticos, a validação pode entrar em fluxo de fallback em vez de falhar de forma determinística quando o algoritmo não corresponde ao conjunto permitido.

O comportamento seguro é: algoritmo permitido, tipo de chave compatível, key id resolvido e validação de claims obrigatórias. Qualquer divergência deve interromper o fluxo com rejeição.

// Fluxo vulneravel simplificado (conceitual)
String alg = token.header().alg();
if (alg.startsWith("HS")) {
    return verifyHmac(token, hmacSecret);
}
// fallback indevido: deveria falhar se o algoritmo nao estiver na policy
return verifyRsa(token, rsaPublicKey);

// Fluxo recomendado (deterministico)
String alg = token.header().alg();
if (!allowedAlgorithms.contains(alg)) {
    throw new CredentialsException("algoritmo nao permitido");
}
Key key = resolveKey(alg, token.header().kid());
verifySignature(token, alg, key);
validateClaims(token, expectedIssuer, expectedAudience, clockSkew);

Versões afetadas e corrigidas

• Versões afetadas informadas: até 6.2.2 e 6.3.2.
• Versões com correção: 6.2.3 e 6.3.3 (ou superiores).
• Módulo impactado: org.pac4j:pac4j-jwt.

<dependency>
  <groupId>org.pac4j</groupId>
  <artifactId>pac4j-jwt</artifactId>
  <version>6.3.3</version>
</dependency>

Cenários de exposição

A exploração depende de pré-condições específicas. Não é apenas a presença da biblioteca, mas a combinação de versão vulnerável com validação criptográfica flexível.

• Serviço exposto aceita bearer token JWT do cliente.
• pac4j-jwt em versão afetada no caminho de autenticação.
• Política de algoritmo não está estritamente fixada.
• Validação de claims (iss/aud/exp/nbf) incompleta ou permissiva.

Em ambiente real, o indicador mais comum é padrão anômalo de autenticação com tokens rejeitados em sequência seguidos por aceitação inesperada para o mesmo IP, usuário alvo ou recurso sensível.

Detecção e telemetria recomendada

Habilite registro estruturado no ponto de autenticação (sem registrar token completo), capturando: algoritmo, key id, issuer, audience, resultado da validação e motivo de rejeição.

• Alerta para uso de algoritmos fora da allowlist (ex.: HS* quando esperado RS*).
• Alerta para alto volume de falhas de assinatura seguidas de sucesso.
• Detecção de reutilização anômala de jti e troca abrupta de kid.
• Correlação entre rota sensível acessada e mudança de perfil/claim no mesmo contexto.

// Exemplo de campos minimos para SIEM
auth_result, reason, alg, kid, iss, aud, subject, source_ip, user_agent, endpoint

// Exemplo de consulta operacional (adaptar para seu SIEM)
service="auth-gateway" event="jwt_validation"
| stats count values(auth_result) as results by source_ip, alg, kid
| where count > 25 OR mvfind(results, "accepted") >= 0

Mitigação recomendada

• Atualizar imediatamente para 6.2.3, 6.3.3 ou superior em todos os serviços.
• Fixar algoritmo permitido por ambiente (lista explícita de permitidos, sem fallback automático).
• Separar material criptográfico por algoritmo e evitar reuso indevido de chaves.
• Validar rigidamente iss, aud, exp, nbf e iat.
• Rotacionar par RSA e invalidar sessões/tokens emitidos antes do patch.
• Reduzir TTL de token e exigir jti para controle de replay em cenários sensíveis.

A rotação de chaves após update não é cosmética: reduz risco residual caso token assinado anteriormente tenha sido aceito de forma indevida no período vulnerável.

Hardening de implementação (Java)

• Centralizar a configuração do autenticador em um único ponto versionado.
• Bloquear algoritmos não utilizados no classpath por política defensiva.
• Exigir kid válido e conhecido no key resolver.
• Aplicar fail closed: erro de parsing/assinatura/claim sempre rejeita autenticação.
• Separar autenticação de autorização: não promover claim para perfil sem validação adicional.

Checklist de validação pós-correção

• Inventário concluído de todos os serviços com pac4j-jwt no caminho de login.
• CI/CD com regra de bloqueio para versões afetadas.
• Política de algoritmo/chave validada por teste automatizado.
• Chaves antigas revogadas e nova cadeia criptográfica auditada.
• Teste negativo para token com algoritmo fora da allowlist.
• Teste negativo para token assinado com chave/tipo incompatível.
• Teste negativo para claims inválidas (iss/aud/exp/nbf).
• Teste de regressão garantindo que usuário legítimo continua autenticando normalmente.

// Exemplo de assercao de regressao (conceitual)
assertThrows(CredentialsException.class, () -> authenticator.validate(forgedToken));
assertDoesNotThrow(() -> authenticator.validate(validToken));

Plano de resposta em 24 horas

• 0-2h: congelar deploys sensíveis, mapear serviços e versões afetadas.
• 2-8h: aplicar patch, validar autenticação negativa e publicar rollback seguro.
• 8-16h: rotacionar chaves, invalidar tokens antigos e reforçar monitoramento.
• 16-24h: revisar logs retroativos, gerar evidências e atualizar runbooks.

Fontes primárias

• CodeAnt Research
• Advisory oficial do pac4j
• NVD - CVE-2026-29000