Apache Camel closes WebSocket dispatch header injection across three release lines

Apache Camel has published a fix for a WebSocket dispatch header-injection flaw affecting three Camel 4 release ranges. The project rates CVE-2026-71300 medium severity and recommends moving to Camel 4.22.0, 4.18.4 or 4.14.9, depending on the release stream.

The issue matters to teams that bridge an HTTP consumer into the camel-atmosphere-websocket producer. In that route shape, an external sender could supply dispatch-related headers that influence which connected WebSocket peer receives a message.

What changed

The affected producer uses Exchange headers to select target peers. Five header values used a dotted websocket. prefix rather than Camel’s filtered namespace, so Camel’s inherited HTTP header filtering did not remove them at the consumer boundary.

An attacker able to send an ordinary inbound HTTP header could inject the list-valued connection header and override the recipient selected by the route. According to the advisory, that could suppress a notification intended for one client or redirect it to another client whose connection key is known to the sender.

Affected versions are Camel 4.0.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.x. The fixed releases are 4.14.9, 4.18.4 and 4.22.0.

Who is affected

The exposed configuration is specific: an untrusted HTTP-family consumer must feed an Atmosphere WebSocket producer whose dispatch is driven by the affected headers. Routes that do not use that component or do not carry untrusted HTTP input into it do not match the path described by the project.

Teams using literal header strings need an additional compatibility check. The fix renames the five values into Camel’s namespace—for example, websocket.connectionKey becomes CamelAtmosphereWebsocketConnectionKey. Java code that refers to the WebsocketConstants fields symbolically continues to work, but routes that set the old strings literally must be updated.

What to do

Upgrade to 4.22.0, 4.18.4 or 4.14.9 for the applicable stream and test routes that set Atmosphere WebSocket dispatch headers. The header rename is security-relevant but can also be a breaking change for literal-string configurations.

If an immediate upgrade is not possible, the project recommends stripping websocket. headers at the trust boundary—for example, by placing removeHeaders("websocket.") between the HTTP consumer and WebSocket producer. It also advises against directly bridging untrusted HTTP input into a header-driven WebSocket producer without removing that dispatch namespace first.