CVE-2026-78329

概要

Apache Camel Undertow コンポーネントにおける不適切な入力検証の脆弱性。この問題は Apache Camel に影響します: 4.11.0 から 4.14.9 未満、4.15.0 から 4.18.4 未満、4.19.0 から 4.22.0 未満。UndertowEndpoint は、その headerFilterStrategy フィールドを基本の HttpHeaderFilterStrategy にデフォルト設定し、そのインスタンスを遅延生成する UndertowHttpBinding に注入して、DefaultUndertowHttpBinding が自身のコンストラクターで設定する UndertowHeaderFilterStrategy を上書きしていました。デプロイメントがカスタム binding または明示的な headerFilterStrategy を提供しない限り、undertow 固有のフィルタリングはエンドポイントで設定されたルート上では決して実行されませんでした。つまり、ストラテジーオブジェクトは参照される前に構築され、すぐに置き換えられていたのです。その結果、従来の websocket. Exchange ヘッダーのプレフィックスが undertow トランスポート境界で双方向ともフィルタリングされませんでした。そのため、undertow HTTP コンシューマーは、その形式のインバウンドワイヤーヘッダーを Exchange にマッピングし、undertow WebSocket プロデューサーはそれらをディスパッチディレクティブとして読み取り、ルートが選択したものとは異なるピアに配信させられる可能性があります。また、undertow 自身が受け入れないヘッダー名もスキップされずに Exchange にマッピングされました。Rest DSL コンシューマーは影響を受けませんでした。UndertowComponent が undertow ストラテジーを拡張する UndertowRestHeaderFilterStrategy を明示的に割り当てるためです。これは CVE-2025-30177 のリグレッションではありません。基本の HttpHeaderFilterStrategy がインバウンドの Camel プレフィックスフィルター自体を設定するため、そのアドバイザリによって導入された保護は基本クラスを通じて引き続き機能し、失われることはありませんでした。この変更によって undertow ストラテジーがエンドポイントパス上で孤立したままになり、その後に書き込まれた2つの修正 - 1つは undertow が拒否するヘッダー名をスキップするもの、もう1つは従来の 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 コンポーネントは、外部に見える API コントラクトの一部として websocket. 値を意図的に保持しており、UndertowProducer は in.getHeader でそれらを読み取りますが、in.getHeader は HeaderFilterStrategy を一切参照しません。したがって、復元されたフィルタリングは undertow トランスポート境界のみでの多層防御です。非 undertow コンシューマーから undertow プロデューサーへ信頼できないメッセージを運ぶルートは、この修正では保護されず、それらのヘッダーを自分で除去する必要があります。

• CVE-2026-78329PoC