CVE-2026-78329 in Camel
要約
〜によって VulDB • 2026年08月24日
Apache Camel Undertow コンポーネントにおける不適切な入力検証の脆弱性。
本問題は Apache Camel に影響を与えます：4.11.0 未満の 4.14.x、4.15.0 未満の 4.18.x、および 4.19.0 未満の 4.22.x のバージョンが対象です。
UndertowEndpoint はその headerFilterStrategy フィールドを基本クラスの HttpHeaderFilterStrategy にデフォルト値として設定し、遅延生成される UndertowHttpBinding インスタンスにこのオブジェクトを設定していました。これにより、DefaultUndertowHttpBinding が自身のコンストラクタでインストールする UndertowHeaderFilterStrategy が上書きされていました。展開時にカスタムバインディングや明示的な headerFilterStrategy が指定されない場合、エンドポイント設定されたルートに対して undertow 固有のフィルタリングは実行されませんでした。その結果、戦略オブジェクトが構築されるとすぐに置き換えられ、参照される機会がありませんでした。
この影響として、レガシーな websocket. Exchange ヘッダー接頭辞が、双方向ともに undertow トランスポート境界でフィルタリングされませんでした。これにより、undertow HTTP コンシューマーはそのような形式の着信ワイヤヘッダーを Exchange にマッピングし、undertow WebSocket プロデューサーはそれらをディスパッチ指示として読み取り、ルートが選択したピアとは異なるピアにメッセージを送信させることが可能になりました。また、Undertow 自体が受け付けないヘッダー名もスキップされることなく Exchange にマッピングされました。
Rest DSL コンシューマーはこの影響を受けませんでした。これは UndertowComponent が明示的に UndertowRestHeaderFilterStrategy を割り当てており、これが undertow 固有の戦略を拡張しているためです。
本問題は CVE-2025-30177 の回帰（regression）ではありません。基本クラスの HttpHeaderFilterStrategy は着信 Camel プレフィックスフィルタ自体を設定するため、そのアドバイザリで導入された保護は基本クラスを通じて継続して機能しており、失われることはありませんでした。本変更が引き起こしたのは、undertow 固有の戦略をエンドポイントパス上で孤立させたことであり、その結果、この戦略に追加されていた2つの修正（Undertow が拒否するヘッダー名をスキップするもの、および双方向でレガシーな websocket. プレフィックスをフィルタリングするもの）は、エンドポイントがもはや使用しないクラスに対して適用され、それらが搭載されたリリースでは効果を持ちませんでした。
ユーザーにはバージョン 4.22.0 にアップグレードすることを推奨します（本問題を修正しています）。4.14.x LTS リリースストリームを使用している場合は 4.14.9 へ、4.18.x リリースストリームを使用している場合は 4.18.4 へのアップグレードを推奨します。直ちにアップグレードできない展開環境では、デフォルトに依存するのではなく戦略を明示的に設定してください。例えば、レジストリに UndertowHeaderFilterStrategy をバインドし、エンドポイントで undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy のように参照します。さらに、信頼境界において removeHeaders("websocket.*") によってディスパッチヘッダーを削除してください。
アップグレード後も解消されない残留制限に注意が必要です。Undertow コンポーネントは意図的に websocket. 値を外部的に見える API 契約の一部として保持しており、UndertowProducer は in.getHeader を用いてそれらを読み取りますが、このメソッドは HeaderFilterStrategy を一切参照しません。したがって、復元されたフィルタリング機能は undertow トランスポート境界における防御の深さ（defence in depth）に留まります。非 Undertow コンシューマーからの信頼できないメッセージを Undetow プロデューサーへ転送するルートは、この修正によって保護されず、それらのヘッダー自体で削除する必要があります。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.