CVE-2026-66908Apache CamelJWTAuthentication Bypass

CVE-2026-66908: o JWT era válido, mas não para a sua API

Assinatura e expiração estavam corretas. Mesmo assim, um token emitido para outro serviço podia atravessar a autenticação do Camel porque issuer e audience não eram validados.

Por Equipe VorvexPublicado em 27 de agosto de 20264 min de leitura

Um JWT com assinatura válida não é automaticamente válido para toda API que confia naquela chave. O token também precisa ter sido emitido pela autoridade esperada e para a audiência correta. A CVE-2026-66908 mostra o que acontece quando essa segunda parte desaparece silenciosamente: o Apache Camel aceitava tokens destinados a outro serviço, desde que estivessem dentro da validade e assinados por uma chave presente no keystore configurado.

Esse cenário é especialmente relevante em empresas que compartilham um provedor de identidade entre várias aplicações. O atacante não precisa falsificar assinatura nem descobrir o segredo do JWT. Ele precisa obter legitimamente um token aceito pelo mesmo domínio de confiança e apresentá-lo a uma API que deveria rejeitar aquele emissor ou aquela audiência.

Technical diagram showing a valid JWT issued for one application being accepted by a different Apache Camel API because issuer and audience validation are missing — A assinatura prova que uma chave confiável emitiu o token. Sem validar issuer e audience, ela não prova que o token pertence àquela API.

O que a CVE-2026-66908 confirma

O Apache classifica a falha como alta e CWE-287, autenticação imprópria. O registro da NVD exibe CVSS 3.1 de 7,5 atribuído ao CISA-ADP, com vetor AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N; a NVD ainda não publicou uma pontuação própria. O componente afetado é o camel-platform-http-main, da versão 4.8.0 até antes da 4.22.0. Tanto o servidor HTTP da aplicação quanto o servidor de gerenciamento passavam pelo caminho vulnerável.

Pré-condição: autenticação JWT habilitada com um keystore e sem jwtIssuer nem jwtAudience
O que continuava sendo validado: assinatura e expiração do token
O que não era validado: as claims iss e aud
Acesso necessário: rede, sem credencial prévia na API alvo
Versão com comportamento fail closed: Apache Camel 4.22.0

Onde a validação desaparecia

Segundo o advisory, JWTAuthenticationConfigurer.buildJwtOptions retornava null quando jwtIssuer e jwtAudience não estavam configurados. O chamador então pulava JWTAuthOptions.setJWTOptions, e o Vert.x JWTAuth era construído apenas com o keystore. O servidor iniciava normalmente, sem aviso de que a política aplicada era mais permissiva que a esperada. As opções de issuer e audience só chegaram à linha principal na versão 4.21.0, então versões anteriores nem ofereciam esse controle naquele componente.

http

GET /orders HTTP/1.1
Host: api-b.example
Authorization: Bearer <unexpired-token-for-api-a-signed-by-a-trusted-key>
Accept: application/json

Formato da verificação em ambiente autorizado. O token deve vir do próprio laboratório e ser válido para outra audiência; não é preciso adulterar assinatura, payload ou algoritmo.

O teste decisivo não é enviar um token inválido. É comparar dois tokens legítimos assinados por uma chave confiável: um com aud correspondente à API e outro emitido para uma audiência diferente. Na configuração vulnerável, ambos podiam atravessar a autenticação. Isso torna o achado fácil de perder em testes que verificam apenas token expirado, assinatura alterada e algoritmo inseguro.

Split security diagram comparing complete JWT validation with signature expiry issuer and audience checks against incomplete validation that checks only signature and expiry — A validação completa liga a credencial ao emissor e ao recurso esperado. Conferir só assinatura e expiração deixa o token reutilizável fora do contexto.

Assinatura não substitui contexto

A assinatura responde se o token foi alterado e se veio de uma chave confiável. A claim iss identifica quem o emitiu; aud limita para qual recurso ele foi criado. Em um provedor multi-tenant ou num keystore que confia em várias chaves, omitir essas duas comparações amplia o conjunto de credenciais aceitas. Mesmo com um único emissor corporativo, um token de uma aplicação interna pode ganhar acesso a outra API sem que o IdP tenha autorizado esse uso.

Mapeie todos os emissores e chaves aceitos pelo keystore, não apenas o IdP nominal
Peça tokens para duas audiências controladas e compare a resposta do mesmo endpoint
Repita o teste no servidor da aplicação e no servidor de gerenciamento
Acesse o backend pelo caminho direto para confirmar que o gateway não é a única camada validando claims
Verifique se erros de autenticação distinguem token expirado, assinatura inválida e audiência incorreta nos logs internos

Como fazer a triagem sem explorar produção

A primeira etapa pode ser inteiramente estática. Confirmamos a versão resolvida no build e procuramos as propriedades de autenticação nos arquivos de aplicação, manifests e charts. O comando abaixo não envia tráfego nem manipula token. Ele revela se o componente está presente e se a configuração menciona os controles relevantes. Segredos não devem ser copiados para o relatório.

bash

./mvnw -q dependency:tree \
  -Dincludes=org.apache.camel:camel-platform-http-main

rg -n 'authenticationEnabled|jwtKeyStore|jwtIssuer|jwtAudience|jwtAllowMissingIssuerAndAudience' \
  src/main/resources deploy charts

Triagem local e somente leitura. Ajuste os diretórios ao repositório e revise valores sensíveis sem imprimi-los em evidências compartilhadas.

Depois da triagem, um teste dinâmico controlado deve usar tokens emitidos para o laboratório e observar também o caminho direto ao Camel. Se a validação de iss e aud existe apenas no API gateway, qualquer rota interna, ingress alternativo ou porta de gerenciamento que contorne o gateway reabre a falha de confiança.

Correção exige atenção à linha de versão

A recomendação principal do Apache é atualizar para 4.22.0. Nessa versão, o servidor se recusa a iniciar com keystore JWT quando issuer e audience estão ambos ausentes, a menos que o operador habilite explicitamente jwtAllowMissingIssuerAndAudience. O valor padrão desse opt-out é false. A mudança transforma uma política implícita e permissiva em uma decisão visível de configuração.

Atualize preferencialmente para Apache Camel 4.22.0 ou posterior
Na linha 4.14.x, use ao menos 4.14.9 e configure jwtIssuer, jwtAudience ou ambos
Na linha 4.18.x, use ao menos 4.18.4 e configure jwtIssuer, jwtAudience ou ambos
Não trate a atualização para 4.14.9 ou 4.18.4 como correção automática, o padrão permissivo foi mantido nessas linhas
Mantenha jwtAllowMissingIssuerAndAudience desabilitado na 4.22.0 ou posterior
Restrinja o keystore ao menor conjunto possível de chaves, idealmente com signer dedicado ao serviço
Garanta que o backend e a interface de gerenciamento não possam contornar a validação feita pelo gateway

O que isso muda no escopo de um pentest

Testar JWT não termina em tentar alg none ou modificar a assinatura. Um pentest de API precisa testar a fronteira entre serviços: token correto para o usuário, mas errado para o recurso; chave confiável, mas emissor inesperado; acesso negado no gateway, mas aceito no backend. A CVE-2026-66908 é um bom exemplo de falha que passa por checklist superficial e aparece quando o teste acompanha a identidade completa, da emissão até cada ponto que toma a decisão de acesso.

← Voltar ao blog