Apache Camel: Camel-Undertow: the endpoint discarded the undertow-specific header filter strategy in favour of the base HTTP one, so the undertow filtering never ran on endpoint-configured routes

Improper input validation vulnerability in Apache Camel Undertow component. This issue affects Apache Camel: from 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. UndertowEndpoint defaulted its headerFilterStrategy field to the base HttpHeaderFilterStrategy and pushed that instance into the UndertowHttpBinding it creates lazily, overwriting the UndertowHeaderFilterStrategy that DefaultUndertowHttpBinding installs in its own constructor. Unless a deployment supplied a custom binding or an explicit headerFilterStrategy, the undertow-specific filtering therefore never executed on endpoint-configured routes: the strategy object was constructed and immediately replaced before it could be consulted. The consequence is that the legacy websocket. Exchange-header prefix was not filtered at the undertow transport boundary in either direction, so an undertow HTTP consumer mapped inbound wire headers of that form onto the Exchange, where an undertow WebSocket producer reads them as dispatch directives and can be made to deliver to a peer other than the one the route selected; and header names that undertow itself does not accept were mapped onto the Exchange rather than being skipped. Rest DSL consumers were never affected, because UndertowComponent assigns UndertowRestHeaderFilterStrategy explicitly, which extends the undertow strategy. This is not a regression of CVE-2025-30177: the base HttpHeaderFilterStrategy configures the inbound Camel-prefix filter itself, so the protection introduced by that advisory continued to work through the base class and was never lost. What the change did was leave the undertow strategy orphaned on the endpoint path, with the effect that two subsequent corrections written into it - one skipping header names undertow rejects, one filtering the legacy websocket. prefix in both directions - were applied to a class the endpoint no longer used and never took effect in the releases that shipped them. 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, configure the strategy explicitly rather than relying on the default, for example by binding an UndertowHeaderFilterStrategy in the registry and referencing it on the endpoint as undertow:http://0.0.0.0:8080/foo?headerFilterStrategy=#myStrategy, and additionally strip the dispatch headers at the trust boundary with removeHeaders(“websocket.*”). Note a residual limitation that upgrading does not remove: the undertow component deliberately keeps the websocket. values as part of its externally visible API contract, and UndertowProducer reads them with in.getHeader, which does not consult a HeaderFilterStrategy at all. The restored filtering is therefore defence in depth at the undertow transport boundary only. A route that carries an untrusted message from a non-undertow consumer into an undertow producer is not protected by this fix and must strip those headers itself.

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 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が上書きされていました。カスタムバインディングや明示的なheaderFilterStrategyが提供されていない限り、エンドポイントに設定されたルート上でundertow固有のフィルタリングは実行されていませんでした。戦略オブジェクトは生成されるもののすぐに置き換えられ、参照されることがありませんでした。その結果、レガシーwebsocket.＜Exchange＞-ヘッダープレフィックスはundertowトランスポート境界で双方向にフィルタリングされず、undertowのHTTPコンシューマーはその形式のインバウンドワイヤーヘッダーをExchangeにマッピングしていました。UndertowのWebSocketプロデューサーはそれらをディスパッチ指示として読み取り、ルートが選択したピアとは異なるピアへ配信される可能性がありました。また、undertow自身が受け入れないヘッダー名もスキップされずにExchangeにマッピングされていました。Rest DSLコンシューマーには影響がありませんでした。なぜなら、UndertowComponentは明示的にUndertowRestHeaderFilterStrategyを割り当てており、これはundertow戦略を拡張しているためです。本件はCVE-2025-30177のリグレッションではありません。ベースのHttpHeaderFilterStrategyはインバウンドのCamelプレフィックスフィルターを自身で構成しているため、該当勧告による保護は基本クラスを通じて引き続き機能していました。今回の変更で起きたのは、undertow戦略がエンドポイントパス上で孤立し、その結果undertowが拒否するヘッダー名をスキップする機能やレガシーwebsocket.プレフィックスを双方向でフィルタリングする機能という2つの修正が、エンドポイントが使用しないクラスに適用され、リリースしたバージョンでは効果を持たなかったということです。ユーザーには、本問題を修正したバージョン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トランスポート境界での多層防御として機能します。非undertowコンシューマーからの信頼できないメッセージをundertowプロデューサーに渡すルートは本修正の保護対象外であり、当該ルート側でそれらのヘッダーを自ら除去する必要があります。