Sploitus

Exploit for CVE-2026-78329

githubexploit Β· 2026-08-24

Exploit Code

README74 lines
## https://sploitus.com/exploit?id=1893947B-BF50-538B-82F8-DCCBDA87EF0B
# CVE-2026-78329 β€” camel-undertow header filter strategy not applied (`websocket.*` injection)

Runnable proof-of-concept reproducer for the Apache Camel vulnerability where `UndertowEndpoint` defaulted its
`headerFilterStrategy` to the base `HttpHeaderFilterStrategy` and pushed that instance into the `UndertowHttpBinding`
it creates, **overwriting** the `UndertowHeaderFilterStrategy` that `DefaultUndertowHttpBinding` installs. Unless a
deployment supplied a custom binding or an explicit `headerFilterStrategy`, the undertow-specific filtering never
ran β€” the strategy object was constructed and immediately replaced before it could be consulted.

| Runtime | Directory | Stack |
|---------|-----------|-------|
| **Camel Spring Boot** | [`camel-spring-boot/`](camel-spring-boot/) | Spring Boot 3.5.13 + camel-undertow **4.18.2** |

> **Camel Quarkus:** there is no `camel-quarkus-undertow` extension (Quarkus uses its own Vert.x HTTP stack), so
> this component cannot be run on Camel Quarkus β€” the reproducer is Spring Boot only.

## What it demonstrates

The consequence is that the legacy `websocket.` Exchange-header prefix is **not filtered** at the undertow
transport boundary in either direction. An undertow HTTP consumer therefore maps inbound wire headers of that form
(`websocket.connectionKey`, `websocket.connectionKey.list`, `websocket.sendToAll`, …) onto the Exchange, where an
undertow **WebSocket producer** reads them as dispatch directives and can be made to deliver to a peer other than
the one the route intended β€” the same dispatch-hijack class as the atmosphere-websocket
[CVE-2026-71300](https://camel.apache.org/security/CVE-2026-71300.html).

This reproducer sends an HTTP request carrying `websocket.*` dispatch headers plus a `Camel*` control header, and
shows what actually reached the Exchange: the `websocket.*` headers cross the boundary (unfiltered), while `Camel*`
is stripped β€” proving the base filter (not the undertow one) was in effect.

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

Expected output on an affected build:

```
What actually reached the Exchange, as echoed by the undertow route:
websocket.connectionKey.list on Exchange = [attacker-connection-key]
websocket.sendToAll on Exchange       = [true]
CamelFoo on Exchange (control)         = []
>>> PROVEN: the undertow endpoint applied the base HttpHeaderFilterStrategy (Camel* filtered) instead of the
>>> UndertowHeaderFilterStrategy, so the legacy websocket.* dispatch headers passed onto the Exchange ...
```

## Vulnerability Summary

| Property | Value |
|----------|-------|
| **Component** | `camel-undertow` (`camel-undertow-starter`) |
| **CWE** | CWE-20 (Improper Input Validation) β†’ CWE-74 (Injection) |
| **Attack vector** | Inbound `websocket.*` headers on an undertow HTTP consumer, read as dispatch directives by an undertow WebSocket producer |
| **Impact** | Take over the WebSocket producer's dispatch decision β€” deliver to / withhold from arbitrary WebSocket peers |
| **Affected Versions** | From 4.11.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0 |
| **Fixed Versions** | 4.14.9, 4.18.4, 4.22.0 |
| **JIRA** | [CAMEL-24360](https://issues.apache.org/jira/browse/CAMEL-24360) |
| **Credit** | Andrea Cosentino (Apache Software Foundation); Barak Srour (Apiiro) |

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

## The fix

The undertow endpoint no longer overwrites the binding's `UndertowHeaderFilterStrategy`, which filters the
`websocket.` prefix (added in CAMEL-23588) in both directions β€” so the dispatch headers are stripped at the
transport boundary and an external sender can no longer inject them.

## Disclaimer

This repository is published for educational and defensive purposes: to help Apache Camel users understand the
vulnerability, verify whether they are affected, and confirm that upgrading resolves it. Do not use this material
against systems you do not own or operate.