CVE-2026-59230 — camel-mail MimeMultipart header injection (headersInline)

Runnable proof-of-concept reproducers for the same Apache Camel vulnerability, one per runtime:

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:

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

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:

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