## https://sploitus.com/exploit?id=7036B588-E9C9-5A2D-B37C-152D367CF63E
# camel-nats Inbound Header Injection Reproducer (CVE-2026-46457)
This project demonstrates a **message-header injection** in Apache Camel's `camel-nats` component, tracked as
**CVE-2026-46457**. The component maps inbound NATS message headers into the Camel Exchange, but `NatsConfiguration`
defaulted its `headerFilterStrategy` to a bare `new DefaultHeaderFilterStrategy()` with **no inbound rules**.
With no `inFilter` / `inFilterPattern` / `inFilterStartsWith` set, `DefaultHeaderFilterStrategy.applyFilterToExternalHeaders`
returns *not filtered* for every header name, so `NatsConsumer` copies every NATS message header โ including
Camel control headers such as `CamelHttpUri`, `CamelFileName` or `CamelSqlQuery` โ unmodified onto the Camel
message. Any client able to publish to the consumed NATS subject can therefore inject arbitrary Camel control
headers that steer downstream producers.
This PoC demonstrates the impact as **server-side request forgery**: injecting `CamelHttpUri` redirects a
downstream `http:` producer to a target of the attacker's choosing.
Advisory: https://camel.apache.org/security/CVE-2026-46457.html
## Vulnerability Summary
| Property | Value |
|----------|-------|
| **Component** | `camel-nats` |
| **Affected Class** | `org.apache.camel.component.nats.NatsConfiguration` (default `DefaultHeaderFilterStrategy`) / `NatsConsumer` |
| **CWE** | CWE-20: Improper Input Validation |
| **Impact** | A subject publisher injects Camel control headers โ steer downstream producers (SSRF shown here) |
| **Preconditions** | NATS 2.2+ (message headers); reachable without credentials on a no-auth NATS server (the default) |
| **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-23515 |
| **Reporter** | Yu Bao (PayPal) |
> Same header-injection family as CVE-2025-27636, CVE-2026-40453, CVE-2026-46454 and CVE-2026-46456. The fix
> makes camel-nats default to a dedicated `NatsHeaderFilterStrategy` that filters the `Camel*` / `camel*`
> namespace case-insensitively on inbound mapping.
## Technical Details
```java
// NatsConfiguration - affected 4.18.2
private HeaderFilterStrategy headerFilterStrategy = new DefaultHeaderFilterStrategy(); // no inbound rules
// NatsConsumer - maps every inbound NATS header; nothing filters the Camel namespace inbound
msg.getHeaders().entrySet().forEach(entry -> {
if (!strategy.applyFilterToExternalHeaders(entry.getKey(), entry.getValue(), exchange)) {
exchange.getIn().setHeader(entry.getKey(), /* value */); // ")
.to("http://localhost:8080/legit-backend?throwExceptionOnFailure=false"); // author's only intended target
```
The camel-http producer honours an inbound `CamelHttpUri` header as the request URI (its default,
non-`bridgeEndpoint`, behaviour). An attacker publishes a message with a NATS header
`CamelHttpUri: http://localhost:8080/internal/secret?leak=...`; the consumer maps it onto the Exchange and the
producer sends the request there instead โ **server-side request forgery**.
> Note: an alternative sink, a `file:` producer steered by an injected `CamelFileName`, is **not** exploitable
> for path traversal *out of* the target directory here, because the camel-file producer jails the filename to
> its starting directory. The `CamelHttpUri` โ SSRF path has no such jail, which is why this PoC uses it.
## Repository layout
The **victim** is the Camel route; the **attacker** is any client that can publish to the subject. The
reproducer runs a real NATS server in Docker; the `/legit-backend` and `/internal/secret` endpoints (and the
attacker driver) live in the app.
```
CVE-2026-46457/
โโโ pom.xml # camel-nats + camel-http 4.18.2
โโโ Dockerfile
โโโ docker-compose.yml # NATS 2.10 + the reproducer app
โโโ README.md
โโโ src/main/
โโโ java/com/example/
โ โโโ Application.java
โ โโโ VictimRoute.java # from("nats:cve").to("http://.../legit-backend")
โ โโโ SinkController.java # /legit-backend and the sensitive /internal/secret
โ โโโ ExploitController.java # attacker: publishes with an injected CamelHttpUri header
โโโ resources/
โโโ application.properties
```
## Prerequisites
- Java 17+ and Maven 3.8+
- Docker (runs NATS)
## Reproduction Steps
### Step 1: Build and start everything
```bash
mvn clean package -DskipTests
docker compose up -d --build
```
### Step 2: Trigger the header injection (SSRF)
```bash
curl -s http://localhost:8080/exploit/attack
# === 1) Legitimate message (no injected header) ===
# reached /legit-backend: true
# === 2) Attack message (CamelHttpUri=http://localhost:8080/internal/secret?leak=...) ===
# redirected to /internal/secret: true (marker seen: ...)
#
# >>> Header-injection / SSRF proof โ attacker redirected the producer to an internal endpoint: true
```
### Cleanup
```bash
docker compose down
```
## Attack Vectors
Any route with a camel-nats consumer feeding a downstream producer whose behaviour is controlled by Camel
headers โ HTTP (`CamelHttpUri`), file (`CamelFileName`, within its jail), SQL (`CamelSqlQuery`), etc. Any client
that can publish to the consumed subject can inject them (no credentials on a default NATS server).
## Exploit Conditions
1. A camel-nats consumer on an affected version, routed to a header-controllable producer.
2. The attacker can publish to the consumed subject (NATS 2.2+; no auth by default).
## Recommended Fix
Upgrade to **4.14.8 / 4.18.3 / 4.21.0** (CAMEL-23515), which defaults to `NatsHeaderFilterStrategy` (inbound
`Camel*` filter).
## Mitigation
Until upgrading:
1. Strip Camel control headers at the start of the route: `.removeHeaders("Camel*")` and
`.removeHeaders("camel*")`.
2. Enable authentication on the NATS server so only trusted clients can publish to the consumed subject.
## 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.