Apache Camel CVE-2026-71300

Requires a Camel route that bridges an HTTP-family consumer directly into a camel-atmosphere-websocket producer whose dispatch is header-driven; this route topology is the essential prerequisite and is not Camel's default for arbitrary deployments. Given that route, no authentication is needed (CVSS PR:N) and a single ordinary inbound HTTP header suffices - the attacker sends websocket.connectionKey.list (or a repeated/bracketed websocket.connectionKey header that Camel's HTTP binding promotes to a List), which is evaluated before the single-key header and overrides the intended recipient. Limiting factors: to redirect (rather than merely suppress) a message to a specific victim client, the attacker must know that client's connection key; suppression requires no such knowledge. Deployments not using this HTTP-into-websocket bridge, or that already strip the websocket.* namespace at the boundary, are not exploitable.

The signals conflict and warrant scrutiny. The vendor CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) implies full confidentiality, integrity and availability compromise, but the described impact is narrower: an attacker can misroute or suppress specific WebSocket notifications, which is primarily an integrity/limited-confidentiality issue rather than 'total' loss of all three - the C:H/I:H/A:H rating appears inflated relative to the described dispatch-hijack behaviour. Supporting this, EPSS is low (0.23%, 13th percentile), SSVC records exploitation as 'none', and there is no KEV listing or public PoC. However, SSVC also flags the issue as Automatable=yes with Technical Impact=total, and exploitation requires only an ordinary inbound HTTP header against a vulnerable route, so where the vulnerable topology exists the barrier to abuse is genuinely low. The key limiting factor is deployment shape: the flaw only bites routes that bridge an untrusted HTTP consumer directly into an atmosphere-websocket producer. Net assessment: patch-worthy and easy to exploit where present, but the real-world blast radius is likely far smaller than the 9.8 suggests, so prioritize it for affected Camel integrations rather than treating it as a blanket critical across all Camel deployments.

An application exposes a Camel route that receives events over HTTP and pushes them to connected clients via the atmosphere-websocket producer. An external sender submits a normal HTTP request carrying a websocket.connectionKey.list header (or a repeated/bracketed header Camel promotes to a list); because that header is not filtered, it overrides the route's chosen recipient, letting the attacker suppress a target user's notification or redirect it to a different connected client whose connection key they know. No public PoC is currently identified, but the attack needs only a single crafted HTTP header (AV:N/AC:L).