oscerd/cve-2026-66907Proof-of-Concept-Reproduktionen für Apache Camel camel-google-storage Pfad-Traversal (CVE-2026-66907), die beliebiges Dateischreiben über downloadFileName demonstrieren, mit Details zu betroffenen und behobenen Versionen.
downloadFileName Path TraversalAusführbare Proof-of-Concept-Reproducer für dieselbe Apache-Camel-Schwachstelle, einer pro Laufzeitumgebung:
| Laufzeitumgebung | Verzeichnis | Stack |
|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-google-storage 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 demonstrieren denselben
Fehler: Der camel-google-storage-Consumer lädt Bucket-Objekte in das lokale Dateisystem herunter, wenn downloadFileName
ein Verzeichnis ist, und baut das lokale Ziel, indem er den entfernten Objektnamen daran anhängt
(downloadFileName + "/${file:name}"). Das Token ${file:name} gibt den Objektnamen unverändert zurück (anders als
${file:onlyname}, das den Pfad entfernt), und das Ergebnis wurde ohne Normalisierung und ohne Prüfung, ob das Ziel innerhalb des
konfigurierten Verzeichnisses blieb, an new File(result) /
blob.downloadTo(file.toPath()) übergeben. Der Objektname wird nicht über die Route gesteuert — der Consumer listet das Bucket und lädt jedes
Objekt herunter —, sodass ein Objekt, dessen Name ../-Segmente enthält, außerhalb von downloadFileName geschrieben wird (CWE-22, Path
Traversal → beliebiges Schreiben von Dateien).
Jedes Unterverzeichnis ist in sich abgeschlossen (eigenes Dockerfile, eigene docker-compose.yml, die einen
fake-gcs-server-Emulator hochzieht, und README). Kurz gesagt, für beide:
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 (beide Varianten):
Files inside the intended download directory /app/downloads:
- report.txt
File written OUTSIDE it, at /tmp/pwned-66907.txt: true
content: PWNED via path traversal — CVE-2026-66907
>>> PROVEN: the object name's ../ segments escaped the configured downloadFileName directory ... : true
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-google-storage (Spring Boot: camel-google-storage-starter; Quarkus: camel-quarkus-google-storage) |
| CWE | CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — Path Traversal) |
| Angriffsvektor | Ein Bucket-Objekt, dessen Name ../-Segmente enthält, heruntergeladen vom Consumer mit downloadFileName gesetzt auf ein Verzeichnis |
| Auswirkung | Beliebige Datei-Schreibvorgänge außerhalb des konfigurierten Download-Verzeichnisses |
| Betroffene Versionen | Von 4.0.0 vor 4.14.9, von 4.15.0 vor 4.18.4, von 4.19.0 vor 4.22.0 |
| Behobene Versionen | 4.14.9, 4.18.4, 4.22.0 |
| JIRA | CAMEL-24279 |
| Credit | n0mi1k |
Der Consumer normalisiert nun den aufgelösten Pfad und stellt sicher, dass er innerhalb des konfigurierten downloadFileName-
Verzeichnisses bleibt (über GoogleCloudStorageFileNameHelper.assertWithinDirectory), und lehnt Objektnamen ab, die es
verlassen würden.
Die docker-compose.yml führt fake-gcs-server mit -backend memory aus. Objektnamen werden dann als opake Map-
Schlüssel behandelt, sodass ein Name mit ../ erhalten bleibt; das Standard-Dateisystem-Backend würde das ../ auflösen und das
Objekt wäre nicht auflistbar.
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache-Camel-Anwendern zu helfen, die
Schwachstelle zu verstehen, zu überprüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade das Problem behebt. Die geschriebene Datei ist ein
harmloser Marker unter /tmp. Verwenden Sie dieses Material nicht gegen Systeme, die Sie nicht besitzen oder betreiben.