Apache Camel: Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result

Relative path traversal vulnerability in Apache Camel Google Storage component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them.

Ein Angreifer kann mehrere Schwachstellen in Apache Camel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, Daten zu manipulieren oder sensible Informationen offenzulegen.

The Cyber Security Agency of Singapore included this CVE in its official Security Bulletin 26 Aug 2026, published on 26 August 2026. Open the linked bulletin for the product, severity and reference information published in that issue.

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}トークンはfile-nameヘッダーをそのまま返しますが、${file:onlyname}はFileUtil.stripPathを適用します。結果として得られた文字列は正規化や保存先が設定ディレクトリ内に収まっているかのチェックを行わずに、そのままnew File(result)およびblob.downloadTo(file.toPath())に渡されます。オブジェクト名はルート管理下のデータではありません。コンシューマーはバケットをリストし、返却されたすべてのBlobを繰り返し処理し、blob.getBlobId().getName()をそのまま使ってオブジェクトごとにExchangeを作成します。これらの名前を制限する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オプションを単純な単一セグメントのオブジェクト名のみを許容する正規表現に設定し、パスセパレータや親ディレクトリセグメントが含まれる名前がExchange作成前に除外されるようにしてください。なお、filterオプション未設定時は全くフィルタリングされず、正規表現はオブジェクト名全体にマッチする点に注意が必要です。あるいは、downloadFileNameに明示的な式（例えば暗黙の${file:name}ではなく${file:onlyname}に基づくもの）を指定して、リモートパスを引き継がないようにしてください。ただし、downloadFileNameに式が含まれる場合、その値はルート管理のものと見なされ、修正で追加された包含チェックの対象外となることに注意してください。防御の深層性の観点からは、外部から書き込み可能なバケットのオブジェクト名を信用できない入力として扱い、それらからローカルファイルシステムのパスを導出しないことを推奨します。