CVE-2026-66906

Zusammenfassung

Schwachstelle durch relativen Pfad-Traversal in der Azure-Storage-Blob-Komponente von Apache Camel. Dieses Problem betrifft Apache Camel: von 4.0.0 bis vor 4.14.9, von 4.15.0 bis vor 4.18.4, von 4.19.0 bis vor 4.22.0. Die Komponente `camel-azure-storage-blob` kann über ihre Operation `downloadBlobToFile` einen Azure-Storage-Blob in das lokale Dateisystem herunterladen und dabei in das Verzeichnis schreiben, das durch die Endpunktoption `fileDir` angegeben wird, die laut Dokumentation sowohl vom Producer als auch vom Consumer verwendet werden kann. `BlobOperations.downloadBlobToFile` baute das lokale Ziel, indem es `fileDir` mit dem entfernten Blob-Namen genau so verknüpfte, wie ihn das Azure SDK zurückgab (`new File(fileDir, client.getBlobName())`), und übergab das Ergebnis direkt an den SDK-Download-Aufruf, ohne lexikalische Normalisierung und ohne Prüfung, ob der aufgelöste Speicherort innerhalb von `fileDir` blieb. Bei dem Blob-Namen handelt es sich nicht um routengesteuerte Daten: Der Consumer durchläuft den Container in `BlobConsumer.createBatchExchangesFromContainer`, der Blobs auflistet und für jeden Eintrag einen Exchange unverändert aus `BlobItem.getName()` erstellt, ohne standardmäßig eine Namensfilterung anzuwenden. Ein Blob-Name, der Elternverzeichnis-Segmente enthält, wurde daher zu einem Speicherort außerhalb des konfigurierten `fileDir` aufgelöst, wodurch jeder, der die Namen im konsumierten Container beeinflussen kann, Camel dazu bringen konnte, eine Datei an einem Ort seiner Wahl mit den Privilegien des Camel-Prozesses zu erstellen oder zu überschreiben. Je nachdem, wohin der Prozess schreiben kann, kann das Überschreiben einer Datei außerhalb des Download-Verzeichnisses über den Integritätsverlust dieser Datei hinaus eskalieren. Azure-Storage-Blob-Container verwenden einen flachen Namespace, in dem der Blob-Name ein undurchsichtiger Schlüssel ist, sodass ein Name mit solchen Segmenten genau so gespeichert und aufgelistet wird, wie er angegeben wurde. Die Option `fileDir` ist ein gewöhnlicher Konfigurationsparameter der common-Gruppe und trägt keinen Sicherheitsmarker, sodass nichts den Benutzern signalisierte, dass ihr Wert nicht als Eindämmungsgrenze durchgesetzt wurde. Die anderen Datei-Download-Consumer von Camel - `camel-file`, `camel-ftp`, `camel-smb`, `camel-mina-sftp` und `camel-azure-files` - haben ihre lokalen Downloads bereits mithilfe einer Pfadsegment-Grenzprüfung auf das konfigurierte Verzeichnis beschränkt; der Download-Pfad von `camel-azure-storage-blob` war von dieser Arbeit nicht abgedeckt. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer im 4.14.x-LTS-Release-Stream sind, wird empfohlen, auf 4.14.9 zu aktualisieren. Wenn Benutzer im 4.18.x-Release-Stream sind, wird empfohlen, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort aktualisieren können, schränken Sie die Namen, auf die der Consumer reagiert, mithilfe der regex-Endpunktoption ein, die auf jeden aufgelisteten Blob-Namen als vollständiger String-Abgleich angewendet wird, sodass nur einfache Namen mit einem einzelnen Segment akzeptiert werden und jeder Name, der einen Pfadtrenner oder ein Elternverzeichnis-Segment enthält, herausgefiltert wird, bevor ein Exchange erstellt wird; die prefix-Option kann die Auflistung zusätzlich serverseitig eingrenzen, wobei zu beachten ist, dass bei beiden regex Priorität hat und prefix ignoriert wird. Alternativ vermeiden Sie die `downloadBlobToFile`-Operation bei nicht vertrauenswürdigen Containern und schreiben Sie die Nutzlast aus der Route unter einem Dateinamen, den die Route selbst kontrolliert, anstatt einen aus der entfernten Auflistung zu übernehmen. Behandeln Sie als Verteidigung in der Tiefe die Blob-Namen in jedem extern beschreibbaren Container als nicht vertrauenswürdige Eingabe und leiten Sie keine lokalen Dateisystempfade daraus ab.