Improper input validation in the Camel-cometd component allows an attacker to send arbitrary headers in a Bayeux (CometD) message. The component copies the whole ext.CamelHeaders map directly onto the Camel Exchange without filtering, providing a CWE‑20 vulnerability. Consequently, attack‑supplied Camel control headers such as CamelHttpUri, CamelFileName, or CamelJmsDestinationName can be injected, allowing an unauthenticated client that completes the Bayeux handshake to alter downstream route behaviour—redirecting HTTP calls, renaming files, or overriding JMS destinations. The injected headers persist across internal direct, seda, and vm hops, so the impact depends on the specific producers used in the route.

Apache Software Foundation’s Apache Camel product, specifically the camel‑cometd component, is affected. All versions from 4.0.0 up to but excluding 4.14.8, from 4.15.0 up to but excluding 4.18.3, and from 4.19.0 up to but excluding 4.21.0 contain the flaw. The fix is available in 4.14.8 for the 4.14.x LTS stream, 4.18.x release stream, and 4.21.0 for newer streams.

The CVSS score of 9.8 indicates a critical severity. The EPSS score is reported as less than 1%, implying a low probability of exploitation at the current time, and the vulnerability is not listed in the CISA KEV catalog. Nevertheless, any deployment that exposes a CometD endpoint without a Bayeux SecurityPolicy can be exploited. Bayeux handshake can publish messages with crafted headers, and because the component accepts them unfiltered, the attacker can influence downstream producers. While that rely on those producers, making prompt remediation advisable.