CVE-2026-95663

Resumo

Vulnerabilidade de Expiração de Sessão Insuficiente no componente Keycloak do Apache Camel. Este problema afeta o Apache Camel: de 4.16.0 antes de 4.18.5, de 4.19.0 antes de 4.22.2. Quando a introspecção de token está habilitada no KeycloakSecurityPolicy do camel-keycloak (useTokenIntrospection=true), o processador de segurança valida o token de acesso de uma requisição enviando-o ao endpoint de introspecção de token OAuth 2.0 do Keycloak, e aceita o token enquanto a resposta o reporta como ativo. O endpoint de introspecção reporta um token como inativo assim que seu tempo exp (expiração) passa, portanto, nesse caminho, o flag active é o que aplica a expiração do token. Os resultados de introspecção são armazenados em cache por padrão (introspectionCacheEnabled=true, introspectionCacheTtl=60 segundos), e ambas as implementações de cache fornecidas com o componente, ConcurrentMapTokenCache e CaffeineTokenCache, expiravam uma entrada após um tempo fixo desde sua inserção, sem limitar esse tempo de vida pela claim exp que a resposta em cache já carregava. O KeycloakSecurityProcessor, por sua vez, verificava apenas o flag active do resultado, em todos os caminhos que usam introspecção, e nunca comparava exp com a hora atual. Uma resposta armazenada em cache pouco antes de o token expirar era, portanto, servida a requisições posteriores que carregavam o mesmo token por até o tempo de vida configurado após a expiração do token, e essas requisições eram admitidas com as funções e permissões que o token expirado carregava, embora a RFC 7662, que define a introspecção de token, estabeleça que uma resposta contendo exp não deve ser armazenada em cache além desse tempo. O token de acesso é fornecido pelo chamador a cada requisição, tipicamente como um bearer token no cabeçalho Authorization, de modo que um chamador que possuísse um token válido momentos antes poderia continuar usando-o após sua expiração, enquanto a entrada em cache permanecesse viva. A janela é limitada por introspectionCacheTtl, que é de 60 segundos por padrão e de 300 a 600 segundos onde a recomendação da documentação para serviços internos foi seguida, e ela se abre apenas para um token que o mesmo processo Camel introspectou e armazenou em cache enquanto o token ainda estava ativo. O problema não concede nada além do que o token já carregava: não permite falsificação de token nem escalonamento de privilégios, e a introspecção de token não está habilitada por padrão, razão pela qual a severidade é avaliada como média. O caminho de verificação JWT local, usado quando a introspecção está desabilitada, não é afetado por este problema. Recomenda-se que os usuários atualizem para a versão 4.23.0, que corrige o problema. Se os usuários estiverem no fluxo de releases 4.22.x, sugere-se que atualizem para 4.22.2. Se os usuários estiverem no fluxo de releases 4.18.x, sugere-se que atualizem para 4.18.5. As linhas de release 4.16.x, 4.17.x e 4.19.x a 4.21.x atingiram o fim de vida antes de este problema ser resolvido e não receberão correção, portanto, implantações nelas devem migrar para uma release suportada. Para implantações que não podem atualizar imediatamente, defina introspectionCacheEnabled=false no KeycloakSecurityPolicy, para que cada requisição seja verificada junto ao endpoint de introspecção, que reporta um token expirado como inativo, ao custo de uma chamada de introspecção por requisição. Reduzir introspectionCacheTtl apenas estreita a janela e não a fecha.

Fontes

• CVE-2026-95663PoC

  Reprodutor de prova de conceito executável para CVE-2026-95663, em que o camel-keycloak do Apache Camel servia resultados de introspecção de token em cache além da expiração do token, com demos em Spring Boot e Quarkus.