Exploit for Improper Input Validation in Apache Camel CVE-2026-46454

## https://sploitus.com/exploit?id=1664446C-5CEA-5E98-AF3C-B69D76D6557D
# 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

| Property | Value |
|----------|-------|
| **Component** | `camel-cometd` |
| **Affected Class** | `org.apache.camel.component.cometd.CometdBinding#createCamelMessage` (`message.setHeaders(...)`) |
| **CWE** | CWE-20: Improper Input Validation |
| **Impact** | Unauthenticated injection of Camel control headers → steer downstream producers (RCE via exec here) |
| **Affected Versions** | From 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0 |
| **Fixed Versions** | 4.14.8, 4.18.3, 4.21.0 |
| **JIRA** | CAMEL-23507 |
| **Reporter** | Yu Bao (PayPal) |

> 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

```java
// CometdBinding.createCamelMessage(...) - affected 4.18.2
Message message = new DefaultMessage(camelContext);
message.setBody(data);
Map headers = getHeadersFromMessage(cometdMessage);   // reads client-supplied ext.CamelHeaders
if (headers != null) {
    message.setHeaders(headers);                                      //  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

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

### Cleanup

```bash
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.