dbcve.org
CamelApplication · Apache

CVE-2026-46454

CRITICAL · 9.8 CVSS v3.1 Published 2026-07-06
Fix available
A fix is available. Upgrade to 4.14.8 / 4.18.3 or later.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click 7 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

The camel-cometd component copies all client-supplied headers from CometD messages directly into the Camel Exchange without filtering, allowing attackers to inject Camel control headers (CamelHttpUri, CamelFileName, etc.) that manipulate downstream producer behavior. No authentication is required as no Bayeux SecurityPolicy is enforced by default.

MitigationUpgrade to Apache Camel 4.21.0 (or 4.14.8/4.18.3 for LTS streams) which implements HeaderFilterStrategy to reject Camel* headers on inbound messages, or implement workaround with removeHeaders('Camel*','camel*') and Bayeux SecurityPolicy if immediate upgrade is not feasible.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
CamelApplication
Affected:>= 4.0.0, < 4.14.8>= 4.15.0, < 4.18.3>= 4.19.0, < 4.21.0

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Apache Camel version
    Run 'camel --version' or check the camel-core JAR manifest, or look for the version in your dependency management (Maven pom.xml, Gradle build.gradle)
    Affected if version falls within >= 4.0.0, < 4.14.8 OR >= 4.15.0, < 4.18.3 OR >= 4.19.0, < 4.21.0
  2. Confirm Cometd component is in use
    Search codebase for 'cometd' in route definitions, or look for 'CometdComponent' in Java/DSL configuration files, or check for 'cometd' endpoint URIs in your Camel routes
    Affected if CometdComponent or cometd endpoint URIs are defined in the application
  3. Check if ext.CamelHeaders are being processed
    Review code that sends messages to cometd endpoints and inspect if the ext.CamelHeaders map is populated with user-controlled data, or examine network traffic to cometd endpoints for presence of 'CamelHeaders' in message extensions
    Affected if Client-provided data can populate the ext.CamelHeaders map in outbound CometD messages
  4. Verify Bayeux SecurityPolicy configuration
    Search for 'SecurityPolicy' configuration on the CometdComponent or BayeuxServer, or check Java code for setSecurityPolicy() calls on the CometdComponent
    Affected if No SecurityPolicy is explicitly configured, meaning unauthenticated clients can connect
  5. Check for HeaderFilterStrategy on Cometd routes
    Search for HeaderFilterStrategy applied to Cometd endpoints, or look for removeHeaders('Camel*') pattern at the start of routes consuming from cometd endpoints
    Affected if No HeaderFilterStrategy is applied and routes accept direct Camel headers from Cometd messages

The environment is affected if running a vulnerable Camel version with CometdComponent in use and no SecurityPolicy or HeaderFilterStrategy is configured to filter Camel control headers from incoming CometD messages.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 4.14.8 / 4.18.3 / 4.21.0 or later
Fixed in 4.14.84.18.34.21.0
Interim mitigation

Upgrade to Apache Camel 4.21.0 (or 4.14.8/4.18.3 for LTS streams) which implements HeaderFilterStrategy to reject Camel* headers on inbound messages, or implement workaround with removeHeaders('Camel*','camel*') and Bayeux SecurityPolicy if immediate upgrade is not feasible.

Recommended fix High confidence

4.21.0 (or 4.14.8 for 4.14.x LTS stream, or 4.18.3 for 4.18.x stream)

  1. Identify your current Camel version by checking your project's dependency management (e.g., pom.xml for Maven, build.gradle for Gradle)
  2. Determine which release stream you are on: 4.14.x LTS, 4.18.x, or 4.19.x/4.20.x
  3. For Maven projects: Update the camel-cometd dependency version in pom.xml to the appropriate fixed version: 4.14.8 (for 4.14.x LTS), 4.18.3 (for 4.18.x), or 4.21.0 (recommended)
  4. Run your build tool to fetch the new dependency (e.g., mvn clean install or gradle build)
  5. Verify the upgrade by running your test suite to ensure the route still functions correctly
  6. Redeploy the application
Caveat Minimal - the fix adds a HeaderFilterStrategy that filters Camel* headers, which is a security enhancement; verify downstream route behavior if you were intentionally passing Camel control headers via CometD

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Camel Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing4.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,080
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,328.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-46454 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-46454 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data