oscerd/cve-2026-78163Lauffähiger Proof-of-Concept-Reproducer für CVE-2026-78163 in Apache Camel camel-docling, der SSRF und lokale Dateioffenlegung über unvalidierte String-Body-Eingabe demonstriert, mit Kontrolle durch einen gefixten Build.
Lauffähiger Proof-of-Concept-Reproduzierer für die Apache-Camel-Schwachstelle, bei der DoclingProducer entschied, was ein
String-Message-Body bedeutet, indem er sein Präfix untersuchte:
http:// oder https:// beginnt, wurde an Docling als abzurufende Remote-URL übergeben (SSRF), und/ beginnt (oder einen Backslash enthält), wurde aus dem lokalen Dateisystem gelesen (Dateioffenlegung).Der Modus wurde implizit gewählt, ohne Endpoint-Option, um eine einzige Interpretation festzulegen, und — anders als der
Camel-Header-Namespace — wird der Message-Body niemals durch eine HeaderFilterStrategy gefiltert. So wurde eine Route, die
bedeutet „konvertiere beliebigen Text, der im Body ankommt", stillschweigend zu einem Abrufer von Remote-Ressourcen oder einem Leser lokaler
Dateien, wann immer der angreiferkontrollierte Text mit einem dieser Präfixe begann.
| Runtime | Verzeichnis | Stack | Zeigt |
|---|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-docling 4.22.0 (betroffen; behoben in 4.22.1) | SSRF und Dateioffenlegung, plus die Kontrolle mit dem behobenen Build |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-docling 3.29.0 (Camel 4.15.0, betroffen) | nur Dateioffenlegung (siehe Hinweis) |
Versionsabdeckung. Die lokale Dateioffenlegungs-Senke existiert seit der Einführung von camel-docling in 4.15.0; die Remote-URL-Senke wurde in 4.16.0 mit docling-serve-Unterstützung hinzugefügt. Das neueste Camel Quarkus (3.29.0) bündelt Camel 4.15.0, daher demonstriert sein Modul nur die Dateioffenlegung. Der Fix wird in Camel 4.18.5 / 4.22.1 / 4.23.0 ausgeliefert; das Spring-Boot-Modul führt sowohl den betroffenen Build (4.22.0) als auch den behobenen Build (4.22.1) aus, sodass es auch das gepatchte Verhalten demonstriert. Kein veröffentlichtes Camel Quarkus bündelt bisher ein behobenes Camel.
Keiner der beiden Reproduzierer benötigt eine echte Docling-Installation: eine winzige gefälschte docling-CLI (fake-docling/docling) steht stellvertretend für
das Binary und macht sichtbar, was das echte mit der vom Producer gelieferten Eingabe tun würde — eine URL abrufen oder eine
Datei lesen. Sie ist harmlos: Sie gibt nur zurück, was sie verarbeiten sollte, und protokolliert ihren eigenen Aufruf. Der Kern der CVE ist,
dass ein angreiferkontrollierter Body überhaupt dieses Argument erreicht, ohne Opt-in.
Die Spring-Boot-App führt außerdem einen nur intern erreichbaren HTTP-Endpoint auf 127.0.0.1:9099 aus (nur Port 8080 ist veröffentlicht,
sodass ein externer Client 9099 nicht direkt erreichen kann) sowie eine lokale geheime Datei. Der Angreifer sendet nur Text:
http://127.0.0.1:9099/internal-secret → der serverseitige docling-Aufruf ruft den
internen Endpoint ab und dessen Geheimnis wird an den Aufrufer zurückgegeben./tmp/cve-2026-78163-secret.txt → die lokale Datei wird gelesen und zurückgegeben.Beim betroffenen Build gelingen beide; beim behobenen Build werden beide mit einer IllegalArgumentException
abgelehnt, die die Option (allowUrlSource / allowFilePathSource) nennt, die erforderlich wäre, um sie zu aktivieren, und docling wird
niemals aufgerufen.
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Erwartete Ausgabe beim betroffenen Spring Boot Build:
[1] SSRF — sending body = http://127.0.0.1:9099/internal-secret
>>> PROVEN SSRF: the server-side docling invocation fetched the attacker-controlled internal URL.
>>> internal victim saw: [GET /internal-secret]
>>> content returned to the caller:
| INTERNAL-SECRET-DATA (only reachable from inside the deployment)
[2] File disclosure — sending body = /tmp/cve-2026-78163-secret.txt
>>> PROVEN file disclosure: the attacker-named local file was read and returned.
| TOP-SECRET-FILE-CONTENT (local file an attacker should not be able to read)
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-docling (camel-docling-starter / camel-quarkus-docling) |
| CWE | CWE-918 (SSRF), CWE-22 (Path Traversal), CWE-200 (Offenlegung von Informationen) |
| Schweregrad | MITTEL |
| Angriffsvektor | Ein String-Nachrichtenkörper, der an einen docling-Endpunkt weitergeleitet wird, dessen Präfix eine URL-Abruf- oder Datei-Lese-Senke auswählt; der Körper unterliegt nicht der HeaderFilterStrategy |
| Auswirkung | Serverseitiger Abruf von vom Angreifer gewählten URLs (interne Dienste) und Offenlegung lokaler Dateien |
| Betroffene Versionen | Ab 4.15.0 vor 4.18.5, ab 4.19.0 vor 4.22.1 (Dateioffenlegung seit 4.15.0; URL-Senke seit 4.16.0) |
| Behobene Versionen | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24422 |
| Danksagung | Li Zhiyao (BUPT) |
Sicherheitshinweis: https://camel.apache.org/security/CVE-2026-78163.html
Ein String-Körper wird nun standardmäßig als das Dokument selbst behandelt. Die beiden Standort-Interpretationen wurden durch
neue Endpunktoptionen allowUrlSource und allowFilePathSource (beide standardmäßig false) zu Opt-in gemacht; ein Körper, der wie eine URL
oder ein Pfad aussieht, wird andernfalls mit einer IllegalArgumentException abgelehnt, die die Option benennt, die ihn aktivieren würde. Eine weitere
Option inputBaseDirectory beschränkt lokale Eingabepfade auf ein konfiguriertes Verzeichnis. Typisierte Körper (File, byte[],
InputStream) und der Header CamelDoclingInputFilePath geben ihre Bedeutung bereits an und werden nicht eingeschränkt (unterliegen aber weiterhin
inputBaseDirectory).
Leiten Sie keine von außen stammenden Nachrichtenkörper an einen docling-Endpunkt weiter; übergeben Sie das Dokument über einen typisierten Körper
(File, byte[], InputStream) oder den Header CamelDoclingInputFilePath, sodass der Körper niemals einer Präfix-
Interpretation unterliegt.
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache Camel-Benutzern zu helfen, die
Schwachstelle zu verstehen, zu überprüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade sie behebt. Die gefälschte docling-CLI und
die „Secrets" sind inaktive lokale Testartefakte. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.