CVE-2026-94386

Riepilogo

Vulnerabilità di uso della cache contenente informazioni sensibili nel componente Oauth di Apache Camel. Il problema riguarda Apache Camel: dalla 4.19.0 alla 4.22.2 esclusa. OAuthClientCredentialsTokenResolver ottiene token bearer OAuth 2.0 tramite il grant client credentials per conto dei componenti che autenticano le proprie chiamate in uscita con un profilo OAuth denominato, come camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat e i componenti IBM watsonx, e delle applicazioni che chiamano direttamente la SPI OAuthClientAuthenticationFactory. Manteneva i token ottenuti in una cache statica condivisa da ogni istanza di resolver e da ogni CamelContext nella JVM, e indicizzava tale cache solo sull'endpoint del token e sul client ID, sebbene la richiesta del token trasporti anche il client secret e lo scope richiesto. Due profili che condividono un endpoint del token e un client ID ma richiedono scope diversi, o si autenticano con client secret diversi, venivano quindi mappati sulla stessa voce di cache: il profilo che risolveva per primo un token popolava la voce, e all'altro profilo veniva poi consegnato quel token, senza alcuna richiesta di token effettuata con la propria configurazione, per tutto il tempo in cui il token rimaneva valido. La cache dei token è abilitata per impostazione predefinita, e indirizzare più profili verso un unico client di un identity provider è un uso ordinario del supporto ai profili, non un'adesione esplicita a un'impostazione non sicura. Il risultato è una richiesta in uscita che trasporta un token emesso per lo scope di un altro profilo, il che può concedere un'autorità più ampia di quella per cui il profilo chiamante era configurato, o raggiungere un servizio per cui il token non era stato emesso; con identity provider che derivano l'audience di un token dallo scope richiesto, uno scope diverso può significare un token per un servizio del tutto diverso. A un profilo configurato con un client secret diverso veniva parimenti servito il token ottenuto con l'altro secret, senza autenticarsi con il proprio. I profili sono configurati dal deployment, che è considerato attendibile, quindi nessun input non attendibile raggiunge la cache: la parte che ne trae vantaggio è il servizio che riceve un token che non avrebbe dovuto ricevere, il quale, se ostile o compromesso, può riprodurre quel token entro il suo scope. Per raggiungere il problema è necessario un deployment che definisca più di un profilo che condivide un endpoint del token e un client ID pur differendo per scope o client secret. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che corregge il problema. Se gli utenti si trovano sul ramo di release 4.22.x, si suggerisce di aggiornare alla 4.22.2. Le linee di release dalla 4.19.x alla 4.21.x hanno raggiunto l'end of life prima che questo problema fosse risolto e non riceveranno una correzione, quindi i deployment su di esse devono passare a una release supportata. Per i deployment che non possono aggiornare immediatamente, disabilitare la cache dei token su ogni profilo OAuth che condivide un endpoint del token e un client ID con un altro profilo, impostando camel.oauth.NAME.cache-tokens=false per un profilo denominato o camel.oauth.cache-tokens=false per quello predefinito, in modo che ogni risoluzione richieda un token con lo scope e il client secret propri di quel profilo, al costo di una richiesta di token a ogni risoluzione. In alternativa, registrare un client separato presso l'identity provider per ogni profilo che necessita di uno scope o di un client secret diversi, in modo che nessuna coppia di tali profili condivida un client ID.

Fonti

• CVE-2026-94386PoC

  Reproducer eseguibile in Spring Boot e Quarkus per CVE-2026-94386, che dimostra il riutilizzo di token OAuth tra scope diversi nella cache statica dei token di camel-oauth di Apache Camel.