Apache Camel の脆弱性の検知と緩和
エグゼクティブサマリー
2025 年 3 月 9 日、Apache Camel で公表された脆弱性 CVE-2025–27636では、リクエストヘッダーの不適切なフィルタリングによりリモートでコードが実行される可能性があることが明らかになりました。
この脆弱性は、ライブラリに存在し、直接的な依存関係と間接的な依存関係の両方を生み出し、検知や緩和を複雑化しています。
このブログ記事では、Akamai の研究者が、脆弱性、悪用手法、 検知戦略に関する詳細な情報を提供します。
Akamai Adaptive Security Engine Rapid Rule は、Akamai App & API Protector のお客様に自動的に保護を適用します。
また、検知のための Akamai Guardicore Segmentation Insight クエリーも提供しています。
- 影響を受けた Akamai Hunt のお客様には、すでに脆弱な資産に関する詳細なマッピングを提供しています。
- 更新情報：2025 年 3 月 11 日、Akamai Security Intelligence Group（SIG）は、Apache Camel セキュリティチームにバイパスを報告しました。2025 年 3 月 12 日、 Apache は新たな CVE： CVE-2025-29891を公表しました。
はじめに
2025 年 3 月 9 日、脆弱性が Apache Camelで修正されました。Apache Camel とは、広く使用されている Java ライブラリです。この脆弱性は Apache によって対処され、バージョン 4.10.2、4.8.5、および 3.22.4 で修正されています。最初の報告では、この脆弱性は重大な影響を及ぼす可能性があると主張していましたが、開発者チームはこの脆弱性に中程度の影響度レベルを割り当てました。
影響度レベルにかかわらず、環境で修正されたバージョンが実行されている場合は、できるだけ早くパッチを適用することを強くお勧めします。一方で、 バージョン 4.10.0、4.10.1、4.8.0 から 4.8.4、および 3.10.0 から 3.22.3 を実行しているアプリケーションは、依然として影響を受ける可能性があります。
この脆弱性を悪用するためには、脆弱なアプリケーションが特定の前提条件を満たす必要があります（この記事の後半 で説明します）。とはいえ、その影響は甚大です。この脆弱性は悪用が簡単で、 リモートコードを実行するなど、破壊的な結果を招く可能性があります。
Camel の普及と、ライブラリに埋め込まれた脆弱性の性質は、今回の発見の重大さを物語っています。このブログ記事は、組織の対応プロセスを支援することを目的としています。
私たちは、この脆弱性を調査し、アプリケーションへの潜在的な影響を説明します。また、検知を構築するためにその悪用手法を分析し、この脆弱性やライブラリに潜む他の脆弱性における最も難しい課題、つまり脆弱なアプリケーションの特定に取り組みます。
Apache Camel とは
Apache Camel は、さまざまなシステム、アプリケーション、クラウドサービス間のシームレスなデータ交換を可能にする、広く使用されているオープンソースの統合フレームワークです。多様な企業環境でメッセージのルーティング、変換、接続をシンプル化します。多くの組織は、重要なビジネスワークフロー、API 統合、マイクロサービスのオーケストレーションに Camel を利用しています。
CVE-20-25-27636 の分析
Apache Camel では、 DefaultHeaderFilterStrategy.java を使用して、内部ヘッダーが外部に転送されないようにしています。これにより、攻撃者が悪用する可能性のある、機密性の高いルーティング情報がヘッダーから漏えいすることを防いでいます。これに該当するヘッダーとしては次のようなものがあります。
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
このフィルタリングは、HTTP ベースのコンポーネントが次のような要求を処理する場合に適用されます。
- camel-http および camel-http4（標準 HTTP の処理）
- camel-rest（REST DSL の処理）
- camel-cxf（Apache CXF Web サービス）
この脆弱性は、Camel によるリクエストヘッダーの不正なフィルタリングに起因します。修正前は、Apache Camel は大文字と小文字を区別するフィルタリングルールを使用していました（図 1）。
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
このロジックは、 Camel や org.apache.camel で始まるヘッダーのみを照合します（図のとおり）。たとえば、攻撃者が大文字小文字を変えて CAmelHttpUri や cAMELHttpResponseCodeにした場合、ヘッダーはフィルタリングされなくなります。
これは、攻撃者が任意のヘッダーをリクエストに挿入し、Camel に内部コンポーネントに転送させることができることを意味します。Apache が アドバイザリーで述べているように、 この脆弱性は、任意の内部メソッドへのアクセスを許可するものではなく、Bean URI で宣言された同じ Bean 内のメソッドへのアクセスのみを許可するものであることに注意してください。これは、悪用するための特定の前提条件の 1 つにすぎません。つまり、脆弱なバージョンの Apache Camel を実行するだけでは、アプリケーションが自動的に脆弱になるわけではないのです。
脅威のテスト
脆弱性を示すために、リモートから悪用できる 脆弱なサンプルアプリケーション を作成しました。このアプリケーションは HTTP ポート 80 でリッスンし、要求を受信すると Camel の「Exec」コンポーネントを使用して whoami コマンドを実行し、その結果をクライアントにエコーします。
curl を使って簡単な要求を送信すると、予想される結果が返されます。つまり、脆弱性にさらされています（図 2）。
Fig. 2: Normal application operation that returns the result of the whoami command
コードからわかるように、 whoami コマンドは静的に定義されているため、コードは比較的安全に見えます。問題は、 Exec がサポートする可能性のある内部メッセージヘッダーを検査するときに発生します。CamelExecCommandExecutable ヘッダーを調べると ヘッダーがコード内の静的 URI で定義された実行可能ファイルを上書きすることがわかります（図3）。
Fig. 3: Apache Camel Exec component documentation
Apache Camel では、 CamelExecCommandExecutableなど、大文字と小文字の区別が一致する内部ヘッダーをフィルターで除外します。しかし、CVE-2025–27636 では、 CAmelExecCommandExecutable （または、大文字と小文字を区別する他の文字）を入力してフィルターをバイパスし、 サーバー上で任意のコマンドを実行することができます （図 4）。
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
同様に、 CAmelExecCommandArgs を指定して、実行されるコマンドにパラメーターを指定することもできます（図 5）。
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
これは、この脆弱性の悪用手口を簡易的に示す例です。任意の内部ヘッダーを挿入できるため、攻撃者はサーバーで使用される Camel コンポーネントに応じて、さまざまなアプリケーションを侵害する可能性があります。
Apache Camel は、CVE-2025-27636 にどのように対処したか？
問題は、文字の大文字と小文字を統一することによって 対処 されました。これにより、攻撃者は大文字と小文字の区別を操作してフィルターをバイパスできなくなります。たとえば、 CAmelHttpUri は camelhttpuriに統一され、フィルターと一致するようになったため、捕捉されます。
.toLowerCase() の導入
GitHub コミットにより DefaultHeaderFilterStrategy.java のヘッダー・フィルタリング・ロジックが更新され、 toLowerCase（Locale.ENGLISH） が含められました。これにより、すべてのヘッダー名を小文字に変換してからフィルターが適用されるようになりました（図 6）。
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
今回の修正により、インジェクションに対する保護に加え、最適化されたチェックを行い、効率性を維持します。最初のチェックで、通常の「Camel」と「camel」のケースを直ちに処理します。この .toLowerCase() チェックは、必要な場合にのみ実行され、不要なパフォーマンスコストを防ぎます。
脆弱なアプリケーションの検知
ネットワーク全体で Apache Camel の脆弱なインスタンスをすべて特定することは困難です。Apache Camel はさまざまな場所に統合されているため、セキュリティチームは幅広い資産を評価する必要があります。これには、防御担当者が認識していないライブラリが使用されているアプリケーションが含まれることもあります。
ライブラリは間接的な依存関係として存在する場合があります。つまり、ソースコードに明示的に含まれていなくても、別のソフトウェアパッケージを通じて導入されるということです。これが、検知の複雑さとともに緩和の複雑さも高めます。
Java アプリケーション内で Apache Camel を特定するには、多くの場合、ディレクトリを再帰的にスキャンして、名前の中に「camel」を含む JAR ファイルを探します。 Camel 関連の JAR ファイルが見つかったら、そのマニフェストファイルを調べ、使用されているバージョンを特定します。
抽出されたバージョンを使用して、セキュリティチームは Apache のセキュリティアドバイザリー と照合して、潜在的な脆弱性を評価できます。影響を受けるのは次のバージョンです。
- 4.10.0 — 脆弱 （4.10.2 以前）
- 4.8.0 — 脆弱 （4.8.5 以前）
- 3.10.0 — 脆弱 （3.22.4 以前）
検出の自動化
脆弱なアプリケーションの特定を容易にするために、当社は、ディレクトリを再帰的にスキャンし、Apache Camel の JAR ファイルを検知し、潜在的に脆弱なアプリケーションを出力する、 PowerShell スクリプトと Bash スクリプト を開発しました。Windows と Linux の両方でお使いいただけます。 影響を受けた Akamai Hunt のお客様には、すでに脆弱な資産に関する詳細なマッピングを提供しています。
Akamai Guardicore Segmentation による検知
Akamai Guardicore Segmentation のお客様向けに、脆弱な資産を識別できる Insight クエリーを構築しました。ファイルバージョンのクエリー結果が「バージョンが見つかりません（Version not found）」である場合、返されたハッシュを、VirusTotal で確認するか、jar 内のマニフェストファイルを通じて確認して、正しいバージョンを取得できます。
Windows
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/../%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Akamai App & API Protector による緩和
2025 年 3 月 7 日（金）、Akamai の脅威リサーチチームは App & API Protector をご利用のお客様向けに、Adaptive Security Engine Rapid Rule を展開しました。
3000911 v2 - Apache Camel (CVE-2025-27636) Attack Detected - Default Action: Deny
Rapid Rules が有効になっており、デフォルトアクションが「Akamai Managed」に設定されているお客様は、この脅威から自動的に保護されます。Rapid Rules を使用しており、デフォルトアクションが「Alert」に設定されているお客様は、すべてのルールトリガーを評価し、ルールアクションを拒否に設定する必要があります。
Rapid Rule 3000911 は、別の方法で Camel の内部フィルタリングロジックを回避していたヘッダーに対してトリガーするように設計されています（図 7）。 このルールは、正当な顧客活動に影響を与えないように、通常の Camel ヘッダーに対してはトリガーされません。
Fig. 7: Rapid Rule 3000911 triggering on attack payload
観測された攻撃トラフィック
Akamai Security Intelligence Group が観測した現在の攻撃ペイロードの狙いは、脆弱性を悪用することではなく、脆弱性を確認することです。観測されたペイロードの大部分は、2 つの異なる戦略を使用して脆弱性を確認しています。
まず、私たちは、ペイロードがアウトオブバンド（OOB）ビーコニングドメインである CAmELDestinationOverrideUrl ヘッダー名を使用しているのを確認しました。このトラフィックは、商用脆弱性スキャンベンダーから発信されており、ペイロード URL は彼らのドメインにビーコンを返しています（図 8）。
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
次に、私たちは、ペイロードがサーバーから特定の HTTP 応答ステータスコードを引き出そうとして CAmelHttpResponseCode ヘッダーを使用するのを確認しました（図 9）。ペイロードが成功した場合、サーバーから返される HTTP 応答ステータスコードは、ペイロードで指定されたものと一致します。
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
最後に、私たちは、上記の両方のペイロードが、 ca%4d%45%6cHttpResponseCode などの単純な URL エンコーディングを使用して検知を回避しようとするのを確認しました（図 10）。しかし、これらの試行は依然として Adaptive Security Engine によって検知され、ブロックされています。
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
更新情報：CVE-2025-29891
Akamai SIG は、Citi Cyber Security Operations と協力して、CVE-2025-27636 の原因となった同じフィルタリングの問題に起因する追加の攻撃ベクトルを特定しました。脆弱なアプリケーションをテストしている際に、リクエストヘッダーに加え、 クエリー文字列と POST 本文のパラメーターも有効な攻撃パスを提供することを特定しました。
図 11では、 CAmelExecCommandExecutable クエリーパラメーターを指定すると、元のヘッダーベクトルと同様に任意のコマンドの実行につながることがわかります。
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
Akamai SIG は、このバイパスを Apache Camel セキュリティチームに報告しました。調査結果の検証が行われ、新たな CVE： CVE-2025-29891が作成されました。CVE-2025-27636 による Apache Camel でのコード修正は、このバイパスも修正しますが、Akamai は 2025 年 3 月 12 日に更新された App & API Protector Rapid Rule 3000911 v3 をリリースし、このギャップに対処する必要がありました。
CVE-2025-27636 を修正する元のパッチはこの問題も解決しているため、最新バージョンの Apache Camel を使用するアプリケーションはこの悪用ベクトルに対して脆弱ではありません。
Akamai は、 GitHub リポジトリを更新し、CVE-2025-29891 とその悪用に関する詳細も対象に含めました。
以前の脆弱性の悪用は、リクエストヘッダーを検査することで検出できましたが、この問題では、リクエストパラメーターもフィルタリングする必要があります。
まとめ
ライブラリ内の脆弱性は、アプリケーションに直接的な影響を与えるだけでなく、未知の場所に潜んでいる可能性があり、検知と緩和が非常に困難になります。Apache Camel は広く使用されているだけでなく、適切なツールセットを持っている攻撃者は、それを活用してリモートでコードを実行することもできます。このため、深刻度がさらに増します。Apache が推奨する行動指針に従い、環境に対して できるだけ早くパッチを適用する ことをお勧めします。
Akamai Security Intelligence Group は、お客様とセキュリティコミュニティ全体のために、このような脅威を監視し、報告し、緩和策を作成し続けます。Akamai Security Intelligence Group からのよりタイムリーなニュースを確認するには、Akamai の リサーチホームページ を確認し、 ソーシャルメディアをフォローしてください。