CVE-2026-94386

Резюме

Уязвимость, связанная с использованием кэша, содержащего конфиденциальную информацию, в компоненте OAuth Apache Camel. Проблема затрагивает Apache Camel: с 4.19.0 до 4.22.2. OAuthClientCredentialsTokenResolver получает bearer-токены OAuth 2.0 через grant типа client credentials от имени компонентов, которые аутентифицируют свои исходящие вызовы с помощью именованного OAuth-профиля, таких как camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat и компонентов IBM watsonx, а также приложений, которые напрямую вызывают SPI OAuthClientAuthenticationFactory. Он сохранял полученные токены в статическом кэше, общем для каждого экземпляра resolver и каждого CamelContext в JVM, и использовал в качестве ключа этого кэша только token endpoint и client ID, хотя запрос токена также содержит client secret и запрашиваемую область действия (scope). Таким образом, два профиля, которые используют общий token endpoint и client ID, но запрашивают разные scope или аутентифицируются с разными client secret, сопоставлялись с одной и той же записью кэша: профиль, который первым получил токен, заполнял запись, а затем другой профиль получал этот токен без выполнения запроса токена в соответствии со своей собственной конфигурацией, пока токен оставался действительным. Кэширование токенов включено по умолчанию, а указание нескольких профилей на одного клиента identity provider является обычным использованием поддержки профилей, а не явным включением небезопасной настройки. Результатом является исходящий запрос, который несёт токен, выпущенный для scope другого профиля, что может предоставить более широкие полномочия, чем те, для которых был настроен вызывающий профиль, или обратиться к сервису, для которого токен не выпускался; в случае identity provider, которые выводят audience токена из запрошенного scope, другой scope может означать токен для совершенно другого сервиса. Профиль, настроенный с другим client secret, аналогичным образом получал токен, полученный с другим секретом, без аутентификации с использованием своего собственного. Профили настраиваются развёртыванием, которое является доверенным, поэтому никакие недоверенные входные данные не попадают в кэш: выигрывает сторона — сервис, который получает токен, не предназначенный для него, и который, если он враждебен или скомпрометирован, может повторно использовать этот токен в пределах его scope. Для достижения проблемы требуется развёртывание, которое определяет более одного профиля, использующего общий token endpoint и client ID, но различающегося по scope или client secret. Пользователям рекомендуется обновиться до версии 4.23.0, в которой исправлена проблема. Если пользователи используют ветку релизов 4.22.x, им рекомендуется обновиться до 4.22.2. Линии релизов с 4.19.x по 4.21.x достигли окончания срока поддержки до того, как эта проблема была устранена, и не получат исправления, поэтому развёртывания на них должны перейти на поддерживаемый релиз. Для развёртываний, которые не могут обновиться немедленно, отключите кэширование токенов для каждого OAuth-профиля, который использует общий token endpoint и client ID с другим профилем, установив camel.oauth.NAME.cache-tokens=false для именованного профиля или camel.oauth.cache-tokens=false для профиля по умолчанию, чтобы каждое разрешение запрашивало токен с собственными scope и client secret этого профиля, ценой запроса токена при каждом разрешении. В качестве альтернативы зарегистрируйте отдельный клиент в identity provider для каждого профиля, которому нужен другой scope или client secret, чтобы никакие два таких профиля не использовали общий client ID.