This vulnerability in Apache Camel's Undertow component involves improper input validation due to the default headerFilterStrategy being overwritten with a base strategy that lacks undertow-specific filtering. As a result, legacy websocket. Exchange-header prefixed headers are not filtered at the transport boundary, allowing them to be mapped onto the Exchange and potentially misdirected by the WebSocket producer. The flaw affects versions >=4.11.0 <4.14.9, >=4.15.0 <4.18.4, and >=4.19.0 <4.22.0. The issue is fixed in versions 4.14.9, 4.18.4, and 4.22.0. Workarounds include explicitly configuring the headerFilterStrategy and removing websocket.* headers at the trust boundary. The fix provides defense in depth at the transport boundary but does not fully protect routes with untrusted messages from non-undertow consumers.

The vulnerability allows legacy websocket. Exchange-header prefixed headers to bypass filtering at the Undertow transport boundary, potentially enabling a WebSocket producer to deliver messages to unintended peers. This could lead to message misrouting or unauthorized message dispatch within affected Apache Camel routes. Rest DSL consumers are not affected. The impact is limited to scenarios where the default headerFilterStrategy is used and untrusted headers are present. There is no indication of active exploitation in the wild.

Users should upgrade to Apache Camel versions 4.14.9, 4.18.4, or 4.22.0 where this issue is fixed. For those unable to upgrade immediately, explicitly configure the UndertowHeaderFilterStrategy by binding it in the registry and referencing it on the endpoint. Additionally, remove websocket.* headers at the trust boundary using removeHeaders("websocket.*"). Note that the fix only restores filtering at the Undertow transport boundary; routes carrying untrusted messages from non-Undertow consumers into Undertow producers must implement their own header stripping to ensure protection.