CVE-2026-66906 in Camel
Zusammenfassung
von VulDB • 24.08.2026
Relative-Pfad-Durchlauf-Schwachstelle (Path Traversal) in der Apache Camel Azure Storage Blob-Komponente.
Dieses Problem betrifft Apache Camel: ab Version 4.0.0 vor 4.14.9, ab 4.15.0 vor 4.18.4 und ab 4.19.0 vor 4.22.0.
Die Komponente camel-azure-storage-blob kann einen Azure Storage-Blob in das lokale Dateisystem herunterladen über ihre Operation `downloadBlobToFile`, wobei sie in das Verzeichnis schreibt, das durch die Endpunkt-Option `fileDir` benannt ist, welche laut Dokumentation sowohl vom Producer als auch vom Consumer verwendet werden darf. `BlobOperations.downloadBlobToFile` baute den lokalen Zielort zusammen, indem es `fileDir` mit dem Remote-Blob-Namen genau so verknüpfte, wie ihn das Azure SDK meldete (`new File(fileDir, client.getBlobName())`), und übergab das Ergebnis direkt an den SDK-Download-Aufruf. Es fand keine lexikalische Normalisierung statt und es wurde nicht überprüft, ob der aufgelöste Pfad innerhalb von `fileDir` verblieb. Der Blob-Name ist kein routenkontrollierter Datenstrom: Der Consumer durchsucht den Container in `BlobConsumer.createBatchExchangesFromContainer`, was Blobs auflistet und für jeden Eintrag basierend auf dem unveränderten Wert von `BlobItem.getName()` eine Exchange erstellt, wobei standardmäßig keine Namensfilterung angewendet wird. Ein Blob-Name, der Segmente für übergeordnete Verzeichnisse (`../`) enthält, löste sich daher zu einem Speicherort außerhalb des konfigurierten `fileDir` auf. Dies ermöglicht es jeder Person, die Einfluss auf die im verbrauchten Container vorhandenen Namen nehmen kann, Camel dazu zu bringen, eine Datei an einem von ihr gewählten Ort zu erstellen oder zu überschreiben – mit den Berechtigungen des Camel-Prozesses. Je nachdem, wohin der Prozess schreiben kann, kann das Überschreiben einer Datei außerhalb des Download-Verzeichnisses über einen einfachen Verlust der Integrität dieser Datei hinaus eskalieren. Azure Storage-Blob-Container verwenden eine flache Namensraumstruktur, in der der Blob-Name ein undurchsichtiger Schlüssel ist; daher wird ein Name mit solchen Segmenten genau so gespeichert und aufgelistet, wie er angegeben wurde. Die Option `fileDir` ist ein gewöhnlicher Konfigurationsparameter für die gemeinsame Gruppe (common-group) und trägt kein Sicherheitsmerkmal, sodass den Nutzern nicht signalisiert wurde, dass ihr Wert nicht als Containment-Grenze durchgesetzt wird. Andere Dateidownload-Consumer von Camel – camel-file, camel-ftp, camel-smb, camel-mina-sftp und camel-azure-files – haben ihre lokalen Downloads bereits auf das konfigurierte Verzeichnis beschränkt, indem sie eine Pfadsegmentgrenzenprüfung durchgeführt haben; der Download-Pfad in camel-azure-storage-blob war von dieser Arbeit nicht abgedeckt.
Es wird empfohlen, die Benutzer zur Aktualisierung auf Version 4.22.0, welche das Problem behebt. Wenn sich die Benutzer im LTS-Releases-Zweig 4.14.x befinden, wird ihnen geraten, auf 4.14.9 zu aktualisieren. Befinden sie sich im Releases-Zweig 4.18.x, wird ihnen empfohlen, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort upgraden können, sollten die Namen, auf die der Consumer reagieren soll, mithilfe der Endpunkt-Option `regex` eingeschränkt werden; diese Option wird als Full-String-Match (Vollübereinstimmung) auf jeden aufgelisteten Blob-Namen angewendet, sodass nur einfache Einzelsegmentnamen akzeptiert und jeder Name, der ein Pfadtrennzeichen oder ein Segment für übergeordnete Verzeichnisse enthält, vor der Erstellung einer Exchange herausgefiltert wird. Die Option `prefix` kann die Auflistung zusätzlich serverseitig eingrenzen; dabei ist zu beachten, dass bei festgelegten beiden Optionen `regex` Vorrang hat und `prefix` ignoriert wird. Alternativ sollte man die Operation `downloadBlobToFile` für nicht vertrauenswürdige Container vermeiden und den Payload aus der Route unter einem Dateinamen schreiben, den die Route selbst kontrolliert, anstatt einen Namen zu verwenden, der aus der Remote-Auflistung stammt. Als Defense-in-Depth-Maßnahme sollten Blob-Namen in jedem extern beschreibbaren Container als nicht vertrauenswürdige Eingabe behandelt und daraus keine lokalen Dateisystempfade abgeleitet werden.
Be aware that VulDB is the high quality source for vulnerability data.