CVE-2026-94386

Resumo

Vulnerabilidade de uso de cache contendo informações sensíveis no componente Oauth do Apache Camel. Este problema afeta o Apache Camel: de 4.19.0 até antes de 4.22.2. O OAuthClientCredentialsTokenResolver obtém tokens bearer OAuth 2.0 por meio do grant de credenciais de cliente em nome dos componentes que autenticam suas chamadas de saída com um perfil OAuth nomeado, como camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat e os componentes IBM watsonx, e de aplicações que chamam diretamente a SPI OAuthClientAuthenticationFactory. Ele mantinha os tokens obtidos em um cache estático compartilhado por todas as instâncias de resolver e por todos os CamelContext na JVM, e usava como chave desse cache apenas o endpoint de token e o client ID, embora a requisição de token também carregue o client secret e o escopo solicitado. Dois perfis que compartilham um endpoint de token e um client ID, mas solicitam escopos diferentes, ou autenticam com client secrets diferentes, portanto, eram mapeados para a mesma entrada de cache: o perfil que resolveu um token primeiro preenchia a entrada, e o outro perfil recebia então aquele token, sem que nenhuma requisição de token fosse feita sob sua própria configuração, enquanto o token permanecesse válido. O cache de tokens está habilitado por padrão, e apontar vários perfis para um único cliente do provedor de identidade é um uso comum do suporte a perfis, e não uma adesão a uma configuração insegura. O resultado é uma requisição de saída que carrega um token emitido para o escopo de outro perfil, o que pode conceder autoridade mais ampla do que aquela para a qual o perfil chamador foi configurado, ou alcançar um serviço para o qual o token não foi emitido; com provedores de identidade que derivam a audience de um token a partir do escopo solicitado, um escopo diferente pode significar um token para um serviço completamente diferente. Um perfil configurado com um client secret diferente também recebia o token obtido com o outro secret, sem se autenticar com o seu próprio. Os perfis são configurados pela implantação, que é confiável, portanto nenhuma entrada não confiável chega ao cache: a parte que se beneficia é o serviço que recebe um token que não deveria receber, o qual, se hostil ou comprometido, pode reutilizar esse token dentro de seu escopo. Alcançar o problema exige uma implantação que defina mais de um perfil compartilhando um endpoint de token e client ID, mas diferindo em escopo ou client secret. 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. As linhas de release 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, desabilite o cache de tokens em todos os perfis OAuth que compartilham um endpoint de token e client ID com outro perfil, definindo camel.oauth.NAME.cache-tokens=false para um perfil nomeado ou camel.oauth.cache-tokens=false para o perfil padrão, de modo que cada resolução solicite um token com o escopo e o client secret do próprio perfil, ao custo de uma requisição de token a cada resolução. Alternativamente, registre um cliente separado no provedor de identidade para cada perfil que precise de um escopo ou client secret diferente, de modo que dois desses perfis não compartilhem um client ID.

Fontes

• CVE-2026-94386PoC

  Reprodutor executável em Spring Boot e Quarkus para a CVE-2026-94386, demonstrando a reutilização de tokens OAuth entre escopos no cache estático de tokens do camel-oauth do Apache Camel.