Apache Camel の脆弱性に対する実行可能な概念実証（PoC）再現ツールです。この脆弱性では、
OAuthClientCredentialsTokenResolver が取得したクライアントクレデンシャルズトークンを、JVM 内のすべてのリゾルバインスタンスとすべての CamelContext で共有される static キャッシュに保持し、そのキャッシュのキーを トークンエンドポイントとクライアント ID のみ としていました — しかしトークンリクエストには クライアントシークレット と 要求スコープ も含まれています。
// affected
record TokenCacheKey(String tokenEndpoint, String clientId) { }
| ランタイム | ディレクトリ | スタック |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-oauth 4.22.1 |
| Camel Quarkus | camel-quarkus/ | Camel Quarkus 3.39.0 (Quarkus 3.39.0, Camel 4.22.0) |
トークンエンドポイントとクライアント ID を共有しながら、異なるスコープを要求する、あるいは 異なるクライアントシークレットで認証する 2 つのプロファイルが、同じキャッシュエントリにマッピングされます。 先に解決されたプロファイルがそのエントリを埋め、もう一方のプロファイルにはそのトークンがそのまま渡されました。 自身の設定の下でトークンリクエストが行われることはなく、トークンが有効である限りこれが続きました。
トークンキャッシュはデフォルトで有効になっており、複数のプロファイルを 1 つのアイデンティティプロバイダークライアントに 向けることは、安全でない設定をオプトインすることではなく、プロファイルサポートの通常の使い方です。
cd camel-spring-boot # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
until curl -sf http://localhost:8080/exploit/ready >/dev/null; do sleep 1; done
curl -s http://localhost:8080/exploit/attack
docker compose down
影響を受けるビルドでの出力（両方のランタイムで同一）：
1) Profile 'invoices' resolves first
token handed to it: TOKEN-FOR[scope=invoice.read;secret=...aaaa]
token requests the IdP has received: 1
2) Profile 'admin' resolves next, through a DIFFERENT resolver instance
token handed to it: TOKEN-FOR[scope=invoice.read;secret=...aaaa]
token requests the IdP has received: 1 (unchanged - no request was made under its own config)
it was handed the token issued for the OTHER profile's scope: true
3) Profile 'partner' - same endpoint and clientId, DIFFERENT client secret (...-zzzz)
token handed to it: TOKEN-FOR[scope=invoice.read;secret=...aaaa]
it was served the token obtained with the other secret, without ever
authenticating with its own: true
4) CONTROL - profile 'admin' again with cache-tokens=false
token handed to it: TOKEN-FOR[scope=admin.write;secret=...aaaa]
it got a token for its own scope: true
Everything the IdP was actually asked for:
- client_id=camel-integration-client scope=invoice.read;secret=...aaaa
- client_id=camel-integration-client scope=admin.write;secret=...aaaa
>>> PROVEN: ...
トークンの値は、それが発行されたスコープとシークレットを表すため、各トークンが実際にどのプロファイルの設定に由来するのかを確認できます。最後のリクエストログが決定的な証拠です。キャッシュが有効な場合、ID プロバイダーは admin プロファイルのトークンをまったく要求されませんでした。表示されるのは最初のプロファイルのリクエストと対照用のリクエストだけです。
プローブ 2 は意図的に2 つ目のリゾルバーインスタンスを使用しています。キャッシュは static であるため、別のインスタンス、つまり別の CamelContext がそれを共有します。
リゾルバーは、名前付き OAuth プロファイルでアウトバウンド呼び出しを認証するコンポーネント、すなわち camel-openai、camel-langchain4j-agent、camel-huggingface、camel-docling、camel-a2a、camel-spring-ai-chat、および IBM watsonx コンポーネント、ならびに OAuthClientAuthenticationFactory SPI を直接呼び出すアプリケーションに代わってトークンを取得します。
この問題に到達するには、トークンエンドポイントとクライアント ID を共有しつつ、スコープまたはクライアントシークレットが異なる複数のプロファイルを定義したデプロイメントが必要です。
プロファイルは信頼されたデプロイメントによって設定されるため、信頼できない入力がキャッシュに到達することはありません。利益を得るのは、本来受け取るはずのないトークンを受け取ったサービスであり、そのサービスが敵対的または侵害されている場合、そのスコープ内でトークンを再生できます。結果として、別のプロファイルのスコープに対して発行されたトークン、つまり呼び出し元プロファイルに設定された権限より広い権限、またはトークンが発行された対象ではないサービス向けのトークンを伴うアウトバウンドリクエストが発生します。要求されたスコープからトークンのオーディエンスを導出する ID プロバイダーでは、スコープが異なればまったく別のサービス向けのトークンになる可能性があります。
ID プロバイダーもネットワークも使用しません。アプリは、クライアントクレデンシャルグラントを提供するプロバイダーのトークンエンドポイントの代替をホストし、発行されたスコープとクライアントシークレットを値に含むトークンを発行し、すべてのリクエストを記録します。実際の OAuthClientCredentialsTokenResolver と実際の静的キャッシュが動作します。
代替実装は、クライアントクレデンシャルをフォームパラメーターではなく HTTP Basic 認証ヘッダーから読み取ります。これは
camel-oauthがそのように送信するためです。
| 項目 | 値 |
|---|---|
| コンポーネント | camel-oauth (OAuthClientCredentialsTokenResolver) |
| CWE | CWE-524 (機密情報を含むキャッシュの使用) |
| 重大度 | 中 |
| 攻撃ベクトル | トークンエンドポイントとクライアント ID を共有しつつ、スコープまたはクライアントシークレットが異なる 2 つ以上の OAuth プロファイル |
| 影響 | 別のプロファイルのスコープに対して発行されたトークン、または別のプロファイルのシークレットで取得されたトークンを伴うアウトバウンドリクエスト |
| 影響を受けるバージョン | 4.19.0 から 4.22.2 より前 |
| 修正済みバージョン | 4.22.2、4.23.0 |
| JIRA | CAMEL-24872 |
| クレジット | Apache Software Foundation の Andrea Cosentino |
アドバイザリ: https://camel.apache.org/security/CVE-2026-94386.html
キャッシュキーは現在、トークンリクエストのすべての入力を保持します。すなわち、トークンエンドポイント、クライアント ID、クライアントシークレットの SHA-256 フィンガープリント（生のシークレットが静的キャッシュに保持されないようにするため）、および要求されたスコープです。スコープが存在しない、空、または空白のみの場合は 1 つの値として扱われます。これは、いずれの場合もリクエストから scope パラメーターが省略されるためです。それ以外のスコープは完全一致で照合されます。4 つすべてが一致するプロファイルはリゾルバーインスタンス間でトークンを共有し続けますが、クレデンシャルまたはスコープが異なるプロファイルは別々のトークンを取得します。
main 上で apache/camel#26681 (5e896b2d) により修正され、#27779 (b2d9957b) で camel-4.22.x にバックポートされました。
camel.version を 4.22.2 に設定して再度実行します。4.22.1 → 4.22.2 に対して検証済みです:
2) Profile 'admin' resolves next, through a DIFFERENT resolver instance
token handed to it: TOKEN-FOR[scope=admin.write;secret=...aaaa]
token requests the IdP has received: 2
it was handed the token issued for the OTHER profile's scope: false
3) Profile 'partner' ... token handed to it: TOKEN-FOR[scope=invoice.read;secret=...zzzz]
it was served the token obtained with the other secret ...: false
>>> NOT reproduced: each profile got a token for its own scope and secret.
4 つのトークンリクエストはすべて、それぞれ独自の設定のもとでアイデンティティプロバイダーに到達するようになりました。
トークンエンドポイントとクライアント ID を別のプロファイルと共有しているすべての OAuth プロファイルで、トークンキャッシュを無効にしてください。名前付きプロファイルでは camel.oauth.NAME.cache-tokens=false、デフォルトプロファイルでは camel.oauth.cache-tokens=false を設定します。ただし、解決のたびにトークンリクエストが発生するというコストを伴います（プローブ 4 では、これが機能することが示されています）。あるいは、異なるスコープやクライアントシークレットを必要とするプロファイルごとに、別個のアイデンティティプロバイダークライアントを登録し、そのようなプロファイル同士がクライアント ID を共有しないようにしてください。
このリポジトリは教育および防御目的で公開されています。Apache Camel ユーザーが脆弱性を理解し、影響を受けているかどうかを確認し、アップグレードによって解決されることを確かめるためのものです。所有または運用していないシステムに対してこの資料を使用しないでください。