CVE-2026-78163
Apache Camel: Unvalidierte Nachrichtenkörper-Eingabequelle in Camel-Docling ermöglicht Server-Side Request Forgery und lokale Dateioffenlegung
- Veröffentlicht
- 19.10.2026
- Aktualisiert
- 19.10.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 17.10.2026
Primäres CVSS
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NZusammenfassung
Server-Side Request Forgery (SSRF), unsachgemäße Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis („Path Traversal") und Offenlegung sensibler Informationen gegenüber einem nicht autorisierten Akteur – Schwachstelle in der Apache Camel Docling-Komponente. Dieses Problem betrifft Apache Camel: von 4.15.0 vor 4.18.5, von 4.19.0 vor 4.22.1. DoclingProducer entschied anhand des Präfixes, was ein String-Nachrichtenkörper bedeutete. Ein Körper, der mit http:// oder https:// begann, wurde an Docling als abzurufende Remote-URL übergeben, ein Körper, der mit / begann oder einen Backslash enthielt, wurde aus dem lokalen Dateisystem gelesen, und alles andere wurde in eine temporäre Datei geschrieben und als Dokumentinhalt konvertiert. Der Modus wurde implizit gewählt, und keine Endpoint-Option erlaubte es einem Route-Autor, die Komponente auf eine einzige Interpretation festzulegen, sodass eine Route, die eigentlich „konvertiere beliebigen Text, der im Body ankommt" bedeutete, stillschweigend zu einem Abrufer von Remote-Ressourcen oder einem Leser lokaler Dateien wurde, sobald der Text zufällig mit einem dieser Präfixe begann. Die einzige Absicherung, die auf den abgeleiteten Wert angewendet wurde, war eine Größenprüfung, und diese Prüfung war in einen Existenztest eingebettet, sodass ein Pfad, der zu nichts auflöste, oder eine Pseudo-Datei, die eine Größe von null meldete, ganz ohne Prüfung durchging. Fünf Aufrufstellen erreichten die beiden Senken: Der CLI-Modus hängte den Wert als letztes Positionsargument des docling-Subprozesses an, und der docling-serve-Modus übergab ihn entweder an HttpSource, damit das Backend ihn abruft, oder an Files.readAllBytes, damit der Inhalt base64-kodiert und hochgeladen werden konnte. Da der Exchange-Body – anders als der Camel-Header-Namespace – niemals durch eine HeaderFilterStrategy gefiltert wird, konnte ein Absender, der Text in eine Nachricht platzieren kann, die eine Route an einen docling-Endpoint weiterleitet, beide Senken ohne jegliche Opt-in-Entscheidung der Deployment-Umgebung erreichen. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Befinden sich Benutzer im Release-Stream 4.22.x, wird ihnen ein Upgrade auf 4.22.1 empfohlen. Befinden sich Benutzer im Release-Stream 4.18.x, wird ihnen ein Upgrade auf 4.18.5 empfohlen. Der Release-Stream 4.14.x und früher erreichte das End-of-Life, bevor dieses Problem behoben wurde, und wird keinen Fix erhalten, sodass Deployments auf diesen Linien auf eine unterstützte Version wechseln müssen. Für Deployments, die nicht sofort aktualisieren können: Leiten Sie keine Nachrichtenkörper, die von außerhalb des Deployments stammen, an einen docling-Endpoint weiter, und übergeben Sie das Dokument über einen typisierten Body wie File, byte[] oder InputStream oder über den Header CamelDoclingInputFilePath, damit der Body niemals der Präfix-Interpretation unterliegt.
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.