CVE-2026-66907 in Camel
要約
〜によって VulDB • 2026年08月24日
Apache CamelのGoogle Storageコンポーネントにおける相対パストラバーサル脆弱性。
本問題は以下のバージョンのApache Camelに影響します: 4.0.0から4.14.9未満、4.15.0から4.18.4未満、4.19.0から4.22.0未満。
camel-google-storageコンシューマーは、downloadFileNameオプションが設定されている場合、Google Cloud Storageのオブジェクトをローカルファイルシステムにダウンロードします。このオプションはフォルダまたはファイル名として文書化されており、その値に式トークンが含まれていない場合、コンシューマーはリモートオブジェクトの名前をそれに追加することでローカルの宛先を作成します: evaluateFileExpressionはExchangeのfile-nameヘッダーにリモートオブジェクトの名前を設定し、「downloadFileName + "/${file:name}"」を評価します。`${file:name}`トークンは、`FileUtil.stripPath`を適用する`${file:onlyname}`とは異なり、ファイル名ヘッダーをそのまま返します。生成された文字列は、レキシカルな正規化や宛先が設定ディレクトリ内に留まっているかのチェックなしで、直接 `new File(result)` および `blob.downloadTo(file.toPath())` に渡されました。オブジェクト名はルート制御データではありません: コンシューマーはバケットをリストアップし、返された各ブロブを反復処理して、`blob.getBlobId().getName()` からそのまま1つのエクチェンジを作成します。これらの名前を制限できるfilterオプションは、明示的に設定されていない限り全く適用されません。Google Cloud Storageのオブジェクト名は、サービスが記載どおりに保存およびリストアップする不透明なUTF-8キーであり、サーバー側の正規化はなく、スラッシュは擬似ディレクトリの表示上の慣習に過ぎないため、親ディレクトリセグメントを含むキーは往復してもそのまま残ります。したがって、そのようなセグメントを含むオブジェクト名は設定されたdownloadFileNameディレクトリの外にある場所へと解決され、消費されるバケット内の名前に影響を与えることができる誰でもが、Camelプロセスの権限で選択した場所にファイルを作成または上書きできるようになります。プロ세스が書き込み可能な内容によっては、ダウンロードディレクトリ外のファイルを上書きすることで、そのファイルの整合性の喪失を超えたエスカレーションが可能となります。downloadFileNameオプションは通常のコンシューマーパラメータでありセキュリティマーカーを持たないため、その値が包含境界として強制されていないことをユーザーに示すものは何もありません。この欠陥はコンシューマーのみに関連し、プロデューサーにはファイルへのダウンロード用シンクがありません。Camelの他のファイルダウンロードコンシューマー（camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files および Azure Storage のダウンロードパス）は、すでに設定されたディレクトリ内にローカルダウンロードを制限するためにパスセグメント境界チェックを行っていましたが、camel-google-storage はその作業でカバーされなかった最後のオブジェクトストア用ダウンロードシンクでした。
ユーザーにはバージョン4.22.0へのアップグレードが推奨されます（本問題を修正しています）。ユーザーが4.14.x LTSリリースストリームに所在する場合は、4.14.9へのアップグレードを提案します。ユーザーが4.18.x リリースストリームに所在する場合は、4.18.4 へのアップグレードを提案します。すぐにアップグレードできないデプロイメントの場合、filterオプションを単純な単一セグメントのオブジェクト名のみを受け入れる正規表現に設定し、パス区切り文字または親ディレクトリセグメントを含む任意の名前がエクチェンジが作成される前に除外されるようにしてください; オプションが未設定の場合はフィルタリングは一切適用されないこと、および式は全体のオブジェクト名に対してマッチングされることに注意してください。あるいは、リモートパスをそのまま渡さない明示的な式（例えば暗黙の `${file:name}` ではなく `${file:onlyname}` に基づくもの）に downloadFileName を与えてください; ただし、downloadFileName が式を含む場合、それはルートの管理者制御下にあるとみなされ、修正で追加された包含チェックの対象外となることに留意してください。防御の多層化として、外部から書き込み可能なバケット内のオブジェクト名を信頼できない入力として扱い、それらからローカルファイルシステムパスを派生させないでください。
Once again VulDB remains the best source for vulnerability data.