## https://sploitus.com/exploit?id=5533AAD7-DD44-558C-8FA6-D94E152D4EE4
# CVE-2026-59230 — camel-mail `MimeMultipart` header injection (`headersInline`)
Runnable proof-of-concept reproducers for the same Apache Camel vulnerability, one per runtime:
| Runtime | Directory | Stack |
|---------|-----------|-------|
| **Camel Spring Boot** | [`camel-spring-boot/`](camel-spring-boot/) | Spring Boot 3.5.13 + camel-spring-boot **4.18.2** |
| **Camel Quarkus** | [`camel-quarkus/`](camel-quarkus/) | Quarkus 3.36.0 + Camel Quarkus 3.36.0 (bundles Camel **4.20.0**) |
Both are **affected** versions (the issue is fixed in 4.14.9 / 4.18.4 / 4.22.0), and both demonstrate the identical
defect: the camel-mail `MimeMultipart` data format, when unmarshalling with `headersInline=true`, copies every
non-standard MIME header of the incoming message onto the Camel `Exchange` via `setHeader` **without applying any
`HeaderFilterStrategy`**. The MIME header names come from the untrusted body, so a sender can place a header in the
Camel-internal namespace (e.g. `CamelHttpUri`) and have it set on the Exchange — even after the route has stripped
`Camel*` headers at the HTTP boundary. A downstream component then reads the injected control header (header
injection → CWE-74).
In these reproducers the injected `CamelHttpUri` redirects the downstream HTTP producer from the intended
`/legit-backend` to an internal `/internal/secret` endpoint (SSRF), visibly returning internal data.
Each subdirectory is a self-contained project with its own `Dockerfile`, `docker-compose.yml`, and README with
full details and reproduction steps. In short, for either:
```bash
cd camel-spring-boot # or: cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
```
Expected output on an affected build:
```
1) Benign MIME (no injected header):
/ingest responded: LEGIT: your message was accepted
2) Malicious MIME (injected MIME header 'CamelHttpUri: http://localhost:8080/internal/secret'):
/ingest responded: SECRET: internal_db_password=S3cr3t-INTERNAL-9f2a
>>> PROVEN: ... redirecting the HTTP producer to an internal service (SSRF): true
```
## Vulnerability Summary
| Property | Value |
|----------|-------|
| **Component** | `camel-mail` — `MimeMultipart` data format (Spring Boot: `camel-mail-starter`; Quarkus: `camel-quarkus-mail`) |
| **CWE** | CWE-20 (Improper Input Validation) → CWE-74 (Injection) |
| **Attack vector** | A crafted MIME multipart body unmarshalled with `headersInline=true` |
| **Impact** | Injection of Camel-internal control headers onto the Exchange (here: `CamelHttpUri` → SSRF) |
| **Affected Versions** | From 2.17.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-23891](https://issues.apache.org/jira/browse/CAMEL-23891) |
| **Credit** | Atuin — Automated Vulnerability Discovery Engine, anciety of Tencent Xuanwu Lab |
Advisory: https://camel.apache.org/security/CVE-2026-59230.html
## The fix
`MimeMultipartDataFormat.copyNonStandardHeaders` now runs each incoming MIME header through a
`MailHeaderFilterStrategy` before setting it on the Exchange, consistent with the inbound filtering the mail
consumer already applies — so `Camel*` headers from the untrusted body are dropped instead of copied verbatim:
```java
// fixed
if (headerFilterStrategy.applyFilterToExternalHeaders(header.getName(), header.getValue(),
camelMessage.getExchange())) {
continue; // filtered
}
camelMessage.setHeader(header.getName(), header.getValue());
```
## 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. The payloads are benign
(a redirect to a local endpoint). Do not use this material against systems you do not own or operate.