CVE-2026-46454: CWE-20 Improper Input Validation in Apache Software Foundation Apache Camel
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.
AI Analysis
Technical Summary
The vulnerability in Apache Camel's camel-cometd component arises because it copies the entire ext.CamelHeaders map from CometD clients directly into the Camel message headers without applying a HeaderFilterStrategy. Since no Bayeux SecurityPolicy is installed by default, any client completing the Bayeux handshake can publish messages with arbitrary Camel control headers. These headers can alter the behavior of downstream producers in the route and persist across internal hops. The vulnerability affects Apache Camel versions from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, and from 4.19.0 before 4.21.0. The fix introduced a case-insensitive HeaderFilterStrategy that blocks client-supplied Camel* headers from being copied into the Exchange. For users unable to upgrade immediately, removing Camel control headers at the start of the route and installing an explicit Bayeux SecurityPolicy to restrict publishing to authenticated clients are recommended mitigations.
Potential Impact
An attacker who can complete the Bayeux handshake against a vulnerable CometD endpoint can inject arbitrary Camel control headers into messages. This can influence downstream producers' behavior, such as redirecting HTTP requests, changing file names, or overriding JMS destinations. The injected headers persist across internal route hops, potentially causing unauthorized actions or data manipulation depending on the route configuration. The impact depends on the specific producers used in the affected routes.
Mitigation Recommendations
A fix is available in Apache Camel versions 4.14.8, 4.18.3, and 4.21.0. Users are strongly recommended to upgrade to these versions to address the vulnerability. For those unable to upgrade immediately, it is advised to strip Camel control headers (e.g., removeHeaders('Camel*') and removeHeaders('camel*')) at the start of the route to prevent header injection. Additionally, installing an explicit Bayeux SecurityPolicy on the CometdComponent to require client authentication before publishing messages will mitigate unauthorized access.
CVE-2026-46454: CWE-20 Improper Input Validation in Apache Software Foundation Apache Camel
Description
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.
CVSS v3.1
Score 9.8critical
Affected software
pkg:maven/Apache Software Foundation/org.apache.camel:camel-cometdRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Apache Camel's camel-cometd component arises because it copies the entire ext.CamelHeaders map from CometD clients directly into the Camel message headers without applying a HeaderFilterStrategy. Since no Bayeux SecurityPolicy is installed by default, any client completing the Bayeux handshake can publish messages with arbitrary Camel control headers. These headers can alter the behavior of downstream producers in the route and persist across internal hops. The vulnerability affects Apache Camel versions from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, and from 4.19.0 before 4.21.0. The fix introduced a case-insensitive HeaderFilterStrategy that blocks client-supplied Camel* headers from being copied into the Exchange. For users unable to upgrade immediately, removing Camel control headers at the start of the route and installing an explicit Bayeux SecurityPolicy to restrict publishing to authenticated clients are recommended mitigations.
Potential Impact
An attacker who can complete the Bayeux handshake against a vulnerable CometD endpoint can inject arbitrary Camel control headers into messages. This can influence downstream producers' behavior, such as redirecting HTTP requests, changing file names, or overriding JMS destinations. The injected headers persist across internal route hops, potentially causing unauthorized actions or data manipulation depending on the route configuration. The impact depends on the specific producers used in the affected routes.
Mitigation Recommendations
A fix is available in Apache Camel versions 4.14.8, 4.18.3, and 4.21.0. Users are strongly recommended to upgrade to these versions to address the vulnerability. For those unable to upgrade immediately, it is advised to strip Camel control headers (e.g., removeHeaders('Camel*') and removeHeaders('camel*')) at the start of the route to prevent header injection. Additionally, installing an explicit Bayeux SecurityPolicy on the CometdComponent to require client authentication before publishing messages will mitigate unauthorized access.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- apache
- Date Reserved
- 2026-05-14T08:45:22.737Z
- Cvss Version
- null
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a4b6cac27e9c79719252297
Added to database: 07/06/2026, 08:51:56 UTC
Last enriched: 07/06/2026, 09:21:28 UTC
Last updated: 07/06/2026, 23:07:48 UTC
Views: 8
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.