CVE-2026-94386

Zusammenfassung

Schwachstelle durch die Verwendung eines Caches mit sensiblen Informationen in der Apache Camel OAuth-Komponente. Dieses Problem betrifft Apache Camel: von 4.19.0 bis vor 4.22.2. OAuthClientCredentialsTokenResolver bezieht OAuth 2.0-Bearer-Tokens über den Client-Credentials-Grant im Namen der Komponenten, die ihre ausgehenden Aufrufe mit einem benannten OAuth-Profil authentifizieren, wie etwa camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat und die IBM-watsonx-Komponenten, sowie im Namen von Anwendungen, die das OAuthClientAuthenticationFactory-SPI direkt aufrufen. Er speicherte die bezogenen Tokens in einem statischen Cache, der von jeder Resolver-Instanz und jedem CamelContext in der JVM gemeinsam genutzt wurde, und bildete den Cache-Schlüssel nur aus dem Token-Endpunkt und der Client-ID, obwohl die Token-Anfrage auch das Client-Secret und den angeforderten Scope enthält. Zwei Profile, die sich einen Token-Endpunkt und eine Client-ID teilen, aber unterschiedliche Scopes anfordern oder sich mit unterschiedlichen Client-Secrets authentifizieren, wurden daher demselben Cache-Eintrag zugeordnet: Das Profil, das zuerst ein Token auflöste, befüllte den Eintrag, und das andere Profil erhielt anschließend dieses Token, ohne dass unter seiner eigenen Konfiguration eine Token-Anfrage gestellt wurde, solange das Token gültig blieb. Das Token-Caching ist standardmäßig aktiviert, und mehrere Profile auf einen Client eines Identity-Providers zu richten, ist eine gewöhnliche Nutzung der Profilunterstützung und keine bewusste Entscheidung für eine unsichere Einstellung. Das Ergebnis ist eine ausgehende Anfrage, die ein Token trägt, das für den Scope eines anderen Profils ausgestellt wurde, was eine breitere Berechtigung gewähren kann, als das aufrufende Profil konfiguriert hatte, oder einen Dienst erreichen kann, für den das Token nicht ausgestellt wurde; bei Identity-Providern, die die Audience eines Tokens aus dem angeforderten Scope ableiten, kann ein anderer Scope sogar ein Token für einen gänzlich anderen Dienst bedeuten. Ein Profil, das mit einem anderen Client-Secret konfiguriert war, erhielt ebenso das mit dem anderen Secret bezogene Token, ohne sich mit seinem eigenen zu authentifizieren. Die Profile werden durch das Deployment konfiguriert, das vertrauenswürdig ist, sodass keine nicht vertrauenswürdige Eingabe den Cache erreicht: Der Nutznießer ist der Dienst, der ein Token erhält, das er nicht erhalten sollte, und der, falls er feindlich gesinnt oder kompromittiert ist, dieses Token innerhalb seines Scopes wiederverwenden kann. Das Erreichen des Problems erfordert ein Deployment, das mehr als ein Profil definiert, die sich einen Token-Endpunkt und eine Client-ID teilen, sich aber in Scope oder Client-Secret unterscheiden. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Befinden sich Benutzer im Release-Zweig 4.22.x, wird ihnen empfohlen, auf 4.22.2 zu aktualisieren. Die Release-Linien 4.19.x bis 4.21.x haben ihr Lebensende erreicht, bevor dieses Problem behoben wurde, und erhalten keinen Fix, sodass Deployments auf diesen Linien auf eine unterstützte Version wechseln müssen. Für Deployments, die nicht sofort aktualisieren können, ist das Token-Caching für jedes OAuth-Profil zu deaktivieren, das sich einen Token-Endpunkt und eine Client-ID mit einem anderen Profil teilt, indem camel.oauth.NAME.cache-tokens=false für ein benanntes Profil oder camel.oauth.cache-tokens=false für das Standardprofil gesetzt wird, sodass jede Auflösung ein Token mit dem eigenen Scope und Client-Secret des jeweiligen Profils anfordert, auf Kosten einer Token-Anfrage bei jeder Auflösung. Alternativ ist beim Identity-Provider für jedes Profil, das einen anderen Scope oder ein anderes Client-Secret benötigt, ein separater Client zu registrieren, sodass keine zwei solcher Profile eine Client-ID teilen.