CVE-2026-46454: Apache Camel-Cometd: Inbound Bayeux message headers are mapped into the Exchange without a HeaderFilterStrategy, allowing unauthenticated clients to inject Camel control headers

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.8%, percentile 57: FIRST’s model estimates a 0.8% chance of exploitation activity in the next 30 days, higher than 57% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes org.apache.camel:camel-cometd (Maven) >= 4.0.0, < 4.14.8, fixed in 4.14.8; org.apache.camel:camel-cometd (Maven) >= 4.15.0, < 4.18.3, fixed in 4.18.3; org.apache.camel:camel-cometd (Maven) >= 4.19.0, < 4.21.0, fixed in 4.21.0. Check your lockfile, including transitive dependencies.

What it is

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.

From the GitHub advisory

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.

Weakness type: CWE-20.

Product: org.apache.camel:camel-cometd (Maven) · Assigned by: apache · Published: 2026-07-06

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: none (no login)
• User interaction: none
• Scope: unchanged

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.83% probability of exploitation activity in the next 30 days; percentile 57.

Timeline

• 2026-07-06 — CVE record last updated
• 2026-07-06 — CVE record published by apache
• 2026-07-06 — GitHub-reviewed advisory GHSA-r9cc-j7wr-p329 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vendor and project advisories, patches

1. camel.apache.org camel.apache.org

Vulnerability records

1. GitHub Advisory GHSA-r9cc-j7wr-p329 github.com
2. CVE.org record CVE-2026-46454 cve.org
3. NVD entry CVE-2026-46454 nvd.nist.gov

Other references from the CVE record and advisory

1. openwall.com openwall.com
2. github.com github.com
3. github.com github.com
4. github.com github.com
5. github.com github.com
6. github.com github.com
7. github.com github.com
8. github.com github.com
9. issues.apache.org issues.apache.org

Critical Maven advisories · Today’s Security Digest