EUVD-2026-41828
GHSA-r9cc-j7wr-p329
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jul 06, 2026
Unauthenticated Camel control-header injection in Apache Camel's camel-cometd component (4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0) lets any client that completes a Bayeux/CometD handshake inject internal headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName into the Camel Exchange, hijacking the behaviour of downstream producers. Because a CometdComponent installs no Bayeux SecurityPolicy by default, no authentication is required (PR:N), and the injected headers survive internal direct/seda/vm hops. Reported by Apache with a fix in 4.21.0; there is no public exploit identified at time of analysis and EPSS is low at 0.19% (9th percentile).
Earlier versions of this analysis (2)
Header injection in the Apache Camel camel-cometd component lets any unauthenticated client that completes a Bayeux/CometD handshake write arbitrary Camel control headers (CamelHttpUri, CamelFileName, CamelJmsDestinationName, etc.) into the Camel Exchange, hijacking the behaviour of downstream producers in the route. It affects Apache Camel 4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0, and is reachable without authentication because a CometdComponent installs no Bayeux SecurityPolicy by default. No public exploit identified at time of analysis; not in CISA KEV, and EPSS is low at 0.19% (9th percentile), consistent with a config-dependent rather than mass-exploitable flaw despite the vendor-assigned 9.8 CVSS.
Header injection in Apache Camel's camel-cometd component allows unauthenticated network clients to manipulate Camel internal control headers - such as CamelHttpUri, CamelFileName, and CamelJmsDestinationName - by supplying them in the ext.CamelHeaders field of a Bayeux handshake message, which the component copies verbatim onto the Exchange without any filtering. Because CometdComponent installs no Bayeux SecurityPolicy by default, any client that can reach the CometD endpoint can perform this injection. The concrete downstream impact varies by route topology: an attacker can redirect HTTP producers to arbitrary URIs (SSRF), reroute file writes, or override JMS destinations, and the injected headers persist across direct, seda, and vm hops within the route. No public exploit code has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Know when Apache Camel gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Unauthenticated network reach (PR:N/AV:N) but impact is contingent on the route using a header-sensitive producer, so AC:H; confidentiality/integrity high via producer hijack, availability only low.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
4DescriptionCVE.org
Improper Input Validation vulnerability in Apache Camel Cometd Component.
The camel-cometd component maps inbound Bayeux (CometD) message headers into the Camel Exchange without applying a HeaderFilterStrategy. CometdBinding.populateExchangeFromMessage copies the entire ext.CamelHeaders map supplied by the CometD client directly onto the Camel message (message.setHeaders), so any header name - including Camel-internal control headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName - is accepted unmodified. Because a CometdComponent installs no Bayeux SecurityPolicy by default, any client that can complete the Bayeux handshake against the CometD endpoint can publish such a message without authentication. An attacker can therefore inject arbitrary Camel control headers that influence the behaviour of downstream producers in the route (for example redirecting an HTTP producer, changing a file name, or overriding a JMS destination); the injected headers also persist across internal direct, seda and vm hops. The concrete downstream impact depends on which producers the route uses. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.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.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix implements a HeaderFilterStrategy in the camel-cometd binding (a long-standing TODO in the code) that filters the Camel header namespace case-insensitively on inbound mapping, so client-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from inbound CometD messages before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), and install an explicit Bayeux SecurityPolicy on the CometdComponent so that only authenticated clients can publish.
Executive ViewAI
Apache Camel's CometD messaging component (versions 4.0-4.20) permits unauthenticated clients to inject routing headers that hijack message processing across internal systems, potentially redirecting sensitive data to unauthorized file systems, message queues, or HTTP endpoints. Any organization exposing a CometD component to network clients without explicit Bayeux security policies is vulnerable-no credentials are required to launch the attack. Patching to version 4.14.8, 4.18.3, or 4.21.0 is critical to restore message routing integrity.
Within 24 hours: Identify all systems using Apache Camel 4.x by searching dependency manifests for camel-cometd and document current versions in use. Within 7 days: Test upgrades to patched versions (4.14.8 LTS, 4.18.3 LTS, or 4.21.0+) in staging and plan maintenance windows. Within 30 days: Deploy patches to all production systems and validate through application logs that CometD message routing functions normally post-upgrade.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
More in Apache Camel
View allRemote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0)
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoS
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.1
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket messag
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remot
Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy im
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an a
Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize)
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to rem
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticate
Exploit-DB