oscerd/cve-2026-59230Proof-of-Concept-Reproducer für Apache Camel camel-mail MimeMultipart Header-Injection (CVE-2026-59230), die SSRF über die CamelHttpUri-Injection in Spring Boot- und Quarkus-Laufzeitumgebungen demonstrieren.
MimeMultipart-Header-Injektion (headersInline)Ausführbare Proof-of-Concept-Reproduktionen für dieselbe Apache-Camel-Schwachstelle, eine pro Laufzeitumgebung:
| Laufzeitumgebung | Verzeichnis | Stack |
|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-spring-boot 4.18.2 |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.36.0 + Camel Quarkus 3.36.0 (bündelt Camel 4.20.0) |
Beide sind betroffene Versionen (das Problem ist in 4.14.9 / 4.18.4 / 4.22.0 behoben), und beide zeigen denselben Defekt: Das MimeMultipart-Datenformat von camel-mail kopiert beim Unmarshalling mit headersInline=true jeden nicht standardkonformen MIME-Header der eingehenden Nachricht über setHeader auf den Camel-Exchange – ohne eine HeaderFilterStrategy anzuwenden. Die MIME-Headernamen stammen aus dem nicht vertrauenswürdigen Body, sodass ein Absender einen Header im camel-internen Namensraum (z. B. CamelHttpUri) platzieren und auf dem Exchange setzen lassen kann – selbst nachdem die Route Camel*-Header an der HTTP-Grenze entfernt hat. Eine nachgelagerte Komponente liest daraufhin den injizierten Steuer-Header (Header-Injektion → CWE-74).
In diesen Reproduktionen leitet der injizierte CamelHttpUri den nachgelagerten HTTP-Producer vom vorgesehenen /legit-backend auf einen internen /internal/secret-Endpunkt um (SSRF), sodass sichtbar interne Daten zurückgegeben werden.
Jedes Unterverzeichnis ist ein eigenständiges Projekt mit eigenem Dockerfile, eigener docker-compose.yml und einer README mit vollständigen Details und Reproduktionsschritten. Kurz gesagt, für beide Varianten:
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
Erwartete Ausgabe auf einem betroffenen 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
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-mail — MimeMultipart-Datenformat (Spring Boot: camel-mail-starter; Quarkus: camel-quarkus-mail) |
| CWE | CWE-20 (Unzureichende Eingabevalidierung) → CWE-74 (Injektion) |
| Angriffsvektor | Ein präparierter MIME-Multipart-Body, der mit headersInline=true unmarshalled wird |
| Auswirkung | Injektion camel-interner Steuer-Header auf den Exchange (hier: CamelHttpUri → SSRF) |
| Betroffene Versionen | Ab 2.17.0 bis vor 4.14.9, ab 4.15.0 bis vor 4.18.4, ab 4.19.0 bis vor 4.22.0 |
| Behobene Versionen | 4.14.9, 4.18.4, 4.22.0 |
| JIRA | CAMEL-23891 |
| Danksagung | Atuin — Automated Vulnerability Discovery Engine, anciety of Tencent Xuanwu Lab |
MimeMultipartDataFormat.copyNonStandardHeaders führt nun jeden eingehenden MIME-Header vor dem Setzen auf dem Exchange durch eine MailHeaderFilterStrategy, konsistent mit der eingehenden Filterung, die der Mail-Consumer bereits anwendet – so werden Camel*-Header aus dem nicht vertrauenswürdigen Body verworfen, statt wörtlich kopiert zu werden:
// fixed
if (headerFilterStrategy.applyFilterToExternalHeaders(header.getName(), header.getValue(),
camelMessage.getExchange())) {
continue; // filtered
}
camelMessage.setHeader(header.getName(), header.getValue());
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache-Camel-Nutzern zu helfen, die Schwachstelle zu verstehen, zu überprüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade das Problem behebt. Die Payloads sind harmlos (eine Weiterleitung auf einen lokalen Endpunkt). Verwenden Sie dieses Material nicht gegen Systeme, die Sie nicht besitzen oder betreiben.