Średni Oczekuje na analizę

CVE-2026-94386

opublikowano: 26.10.2026, 16:16

modyfikacja: 26.10.2026, 17:54

Ocena CVSS

4.8

Średni · v3.1

Oficjalne źródła

wektor: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Wykorzystanie luki w zabezpieczeniach pamięci podręcznej zawierającej poufne informacje w komponencie Apache Camel Oauth.

Ten problem dotyczy Apache Camel: od 4.19.0 do 4.22.2.

OAuthClientCredentialsTokenResolver uzyskuje tokeny nośnika OAuth 2.0 poprzez przyznanie poświadczeń klienta w imieniu komponentów uwierzytelniających jego wywołania wychodzące za pomocą nazwanego profilu OAuth, takich jak camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat i komponenty IBM watsonx, oraz aplikacji wywołujących bezpośrednio SPI OAuthClientAuthenticationFactory. Przechowywał uzyskane tokeny w statycznej pamięci podręcznej współdzielonej przez każdą instancję programu tłumaczącego i każdy CamelContext w maszynie JVM i wpisywał tę pamięć podręczną tylko w punkcie końcowym tokenu i identyfikatorze klienta, chociaż żądanie tokena zawiera również klucz tajny klienta i żądany zakres. Dwa profile, które mają wspólny punkt końcowy tokenu i identyfikator klienta, ale żądają różnych zakresów lub uwierzytelniają się przy użyciu różnych kluczy tajnych klienta, są zatem mapowane na ten sam wpis w pamięci podręcznej: profil, który rozpoznał token, najpierw wypełnił wpis, a następnie drugi profil otrzymał ten token, bez żądania tokenu wysłanego w ramach własnej konfiguracji, tak długo, jak token pozostawał ważny. Buforowanie tokenów jest domyślnie włączone, a skierowanie kilku profili do jednego klienta dostawcy tożsamości jest zwykłym korzystaniem z obsługi profili, a nie wyrażeniem zgody na niezabezpieczone ustawienie. Wynikiem jest żądanie wychodzące zawierające token wystawiony dla zakresu innego profilu, który może przyznać szersze uprawnienia niż profil wywołujący lub dotrzeć do usługi, dla której token nie został wystawiony; w przypadku dostawców tożsamości, którzy czerpią odbiorców tokena z żądanego zakresu, inny zakres może oznaczać token dla zupełnie innej usługi. Profil skonfigurowany z innym sekretem klienta również otrzymał token uzyskany z innym sekretem, bez uwierzytelniania przy użyciu własnego sekretu. Profile są konfigurowane przez wdrożenie, które jest zaufane, więc żadne niezaufane dane wejściowe nie docierają do pamięci podręcznej: stroną, która zyskuje, jest usługa, która otrzymuje token, którego nie miała otrzymać, który, jeśli jest wrogi lub naruszony, może odtworzyć ten token w swoim zakresie. Rozwiązanie problemu wymaga wdrożenia, które definiuje więcej niż jeden profil współdzielący punkt końcowy tokenu i identyfikator klienta, różniący się zakresem lub kluczem tajnym klienta.

Użytkownikom zaleca się aktualizację do wersji 4.23.0, która rozwiązuje problem. Jeśli użytkownicy korzystają ze strumienia wydań 4.22.x, sugeruje się im aktualizację do wersji 4.22.2. Linie wydań od 4.19.x do 4.21.x dobiegły końca przed rozwiązaniem tego problemu i nie otrzymają poprawki, więc wdrożenia w nich muszą zostać przeniesione do obsługiwanej wersji. W przypadku wdrożeń, których nie można uaktualnić natychmiast, wyłącz buforowanie tokenów w każdym profilu OAuth, który współdzieli punkt końcowy tokenu i identyfikator klienta z innym profilem, ustawiając camel.oauth.NAME.cache-tokens=false dla nazwanego profilu lub camel.oauth.cache-tokens=false dla profilu domyślnego, tak aby każde rozwiązanie wymagało tokenu z własnym zakresem tego profilu i sekretem klienta, kosztem żądania tokenu przy każdym rozwiązaniu. Alternatywnie możesz zarejestrować osobnego klienta u dostawcy tożsamości dla każdego profilu, który wymaga innego zakresu lub klucza tajnego klienta, tak aby żadne dwa takie profile nie miały wspólnego identyfikatora klienta.

Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.

This issue affects Apache Camel: from 4.19.0 before 4.22.2.

OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.

Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.

>_ Słabości (CWE)

CWE-524

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve