CVE-2026-46454
Received Received - Intake

Improper Input Validation in Apache Camel Cometd Component

Publication date: 2026-07-06

Last updated on: 2026-07-06

Assigner: Apache Software Foundation

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 Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-07-06
Last Modified
2026-07-06
Generated
2026-07-06
AI Q&A
2026-07-06
EPSS Evaluated
N/A
NVD
CVE-2026-46454
EUVD
EUVD-2026-41828

Affected Vendors & Products

Showing 6 associated CPEs
Vendor Product Version / Range
apache camel 4.0.0
apache camel to 4.14.8 (inc)
apache camel 4.15.0
apache camel to 4.18.3 (inc)
apache camel 4.19.0
apache camel 4.21.0

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-20 The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is an improper input validation issue in the Apache Camel camel-cometd component. It occurs because inbound Bayeux (CometD) message headers are mapped directly into the Camel Exchange without filtering, allowing any header name, including sensitive Camel-internal control headers, to be accepted unmodified.

Since the CometdComponent does not install a Bayeux SecurityPolicy by default, any client that completes the Bayeux handshake can publish messages without authentication. This enables an attacker to inject arbitrary Camel control headers that can influence the behavior of downstream producers in the route, such as redirecting HTTP requests, changing file names, or overriding JMS destinations.

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 issue is fixed in versions 4.14.8, 4.18.3, and 4.21.0 by implementing a HeaderFilterStrategy that blocks client-supplied Camel* headers during inbound mapping.

Impact Analysis

This vulnerability can impact you by allowing unauthenticated attackers to inject arbitrary Camel control headers into your message routes. This can manipulate the behavior of downstream producers, potentially causing unauthorized redirection of HTTP requests, modification of file names, or overriding JMS destinations.

Such manipulation can lead to unauthorized access, data leakage, or disruption of service workflows depending on how the affected routes and producers are configured in your Apache Camel deployment.

Detection Guidance

This vulnerability involves the injection of arbitrary Camel control headers into the Camel Exchange via CometD messages. Detection would involve monitoring CometD message traffic for unexpected or unauthorized Camel control headers such as CamelHttpUri, CamelFileName, or CamelJmsDestinationName.

Since the vulnerability arises from inbound Bayeux message headers being mapped without filtering, you can inspect incoming CometD messages for headers starting with 'Camel' or 'camel'.

While no specific commands are provided in the resources, a practical approach would be to capture and analyze CometD traffic using network tools (e.g., tcpdump, Wireshark) or application-level logging to identify messages containing suspicious Camel* headers.

Mitigation Strategies

The recommended immediate mitigation steps are to upgrade Apache Camel to a fixed version: 4.14.8, 4.18.3, or 4.21.0 depending on your release stream.

If upgrading immediately is not possible, you should:

  • Strip Camel control headers from inbound CometD messages before they reach any downstream producer by using removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route.
  • Install an explicit Bayeux SecurityPolicy on the CometdComponent to ensure that only authenticated clients can publish messages.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46454. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart