CVE-2026-71300: Apache Camel: Camel-Atmosphere-Websocket: WebSocket dispatch header injection

Published Aug 24, 2026
·
Updated

Improper input validation vulnerability in Apache Camel Atmosphere Websocket component.

This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.

The camel-atmosphere-websocket producer selects which connected WebSocket peers a message is delivered to through Exchange headers, and the string values of those headers sat outside the Camel namespace: websocket.connectionKey and websocket.connectionKey.list, along with websocket.sendToAll, websocket.eventType and websocket.errorType. WebsocketEndpoint extends ServletEndpoint and so inherits HttpHeaderFilterStrategy, which filters only the Camel and camel prefixes; the dotted names therefore fell outside the filtered namespace and were admitted in both directions by every HTTP-family consumer. In a route bridging an HTTP consumer into an atmosphere-websocket producer, an external sender could supply the list header and take over the producer's dispatch decision. WebsocketProducer.process tests the list header before the single-key header, so an injected value discarded the recipient the route had selected: a notification intended for one connected client could be suppressed, or delivered instead to a different client whose connection key the sender knows. The header need not be a query parameter and need not be supplied as a list literally - Camel's HTTP binding promotes a repeated header name, and a bracketed value, to a List when mapping onto the Exchange - so an ordinary inbound HTTP header is sufficient to reach the list-valued branch. This is distinct from CVE-2026-55993, which concerns the consumer-side query-parameter path in the same component. The behaviour dates back to the introduction of these constants, first released in 2.17.0, and was unchanged until this fix.

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, strip the dispatch headers at the trust boundary before the producer, for example with removeHeaders(“websocket.”) placed between the HTTP consumer and the atmosphere-websocket producer. Note that the fix renames the header string values into the Camel namespace, which is a breaking change for routes that set them by literal string: routes referencing the WebsocketConstants fields symbolically are unaffected, and the change is documented in the upgrade guides. As defence in depth, do not bridge an untrusted HTTP consumer directly into a WebSocket producer whose dispatch is header-driven without stripping the dispatch namespace first.

Affected Software

4 affected components
Apache Apache Camel>4.0.0<4.14.9, >4.15.0<4.18.4, >4.19.0<4.22.0
Apache Camel>=4.0.0<4.14.9
Apache Camel>=4.15.0<4.18.4
Apache Camel>=4.19.0<4.22.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Apache Camel (camel-atmosphere-websocket) to a version that resolves this vulnerability.

    Fixed in 4.14.9
  2. Upgrade

    Upgrade Apache Camel (camel-atmosphere-websocket) to a version that resolves this vulnerability.

    Fixed in 4.18.4
  3. Upgrade

    Upgrade Apache Camel (camel-atmosphere-websocket) to a version that resolves this vulnerability.

    Fixed in 4.22.0
  4. Configuration

    For deployments that cannot upgrade immediately, strip the dispatch headers at the trust boundary before the atmosphere-websocket producer by inserting a removeHeaders("websocket.*") step between the HTTP consumer and the atmosphere-websocket producer.

    Apache Camel route (HTTP consumer -> atmosphere-websocket producer) removeHeaders('websocket.*') at the trust boundary = true
  5. Compensating control

    If you cannot upgrade immediately, do not bridge an untrusted HTTP consumer directly into an atmosphere-websocket producer whose dispatch is header-driven without stripping the dispatch namespace first (strip websocket.* headers at the trust boundary before the producer).

Event History

Aug 24, 2026
CVE Published
via MITRE·04:21 PM
Data Sourced
via MITRE·04:21 PM
DescriptionWeakness
Data Sourced
via NVD·05:18 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to external manipulation of WebSocket message recipients?

Routes that bridge an HTTP-family consumer to a camel-atmosphere-websocket producer are exposed, because HTTP request headers can be admitted into the exchange and influence the producer's dispatch headers. The issue affects Camel 4.0.0 through before 4.14.9, 4.15.0 through before 4.18.4, and 4.19.0 through before 4.22.0.

2

What does an attacker need to exploit this issue?

An external sender needs to be able to submit a request to an HTTP-family consumer that feeds an Atmosphere WebSocket producer. They can supply the websocket.connectionKey.list header, which is checked before the single-recipient header and can override the recipient selected by the route.

3

What is the practical impact on message delivery?

An injected recipient-list value can take control of the producer's dispatch decision. A notification intended for one connected client can be suppressed, and the attacker-controlled list determines delivery targets.

4

Which upgrade versions address the affected release lines?

Upgrade the 4.0.x line to 4.14.9 or later, the 4.15.x line to 4.18.4 or later, or the 4.19.x line to 4.22.0 or later.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203