CVE-2026-66907

Zusammenfassung

Sicherheitslücke durch relativen Pfad-Traversal in der Google-Storage-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. Der camel-google-storage-Consumer lädt Google-Cloud-Storage-Objekte in das lokale Dateisystem herunter, wenn die Option downloadFileName gesetzt ist. Diese Option ist als Ordner oder Dateiname dokumentiert, und wenn ihr Wert kein Ausdrucks-Token enthält, erstellt der Consumer das lokale Ziel, indem er den Objektnamen anhängt: evaluateFileExpression setzt den Dateinamen-Header der Exchange auf den Namen des Remote-Objekts und wertet downloadFileName + "/${file:name}" aus. Das Token ${file:name} gibt den Dateinamen-Header unverändert zurück, im Gegensatz zu ${file:onlyname}, das FileUtil.stripPath darauf anwendet. Die resultierende Zeichenkette wurde direkt an new File(result) und blob.downloadTo(file.toPath()) übergeben, ohne lexikalische Normalisierung und ohne Prüfung, ob das Ziel innerhalb des konfigurierten Verzeichnisses blieb. Die Objektnamen sind keine von der Route kontrollierten Daten: Der Consumer listet den Bucket auf, iteriert über jedes zurückgegebene Blob und erstellt pro Objekt einen Exchange aus dem unveränderten blob.getBlobId().getName(); die Filteroption, die diese Namen einschränken könnte, wird überhaupt nicht angewendet, sofern sie nicht explizit gesetzt wurde. Google-Cloud-Storage-Objektnamen sind opake UTF-8-Schlüssel, die der Dienst exakt so speichert und auflistet, wie sie geschrieben wurden, ohne serverseitige Kanonisierung; ein Schrägstrich ist nur eine Anzeigekonvention für Pseudo-Verzeichnisse, sodass ein Schlüssel, der übergeordnete Verzeichnissegmente enthält, einen Round-Trip unversehrt übersteht. Ein Objektname, der solche Segmente enthält, wurde daher zu einem Speicherort außerhalb des konfigurierten downloadFileName-Verzeichnisses aufgelöst. Dadurch konnte jeder, der die in dem konsumierten Bucket vorhandenen Namen beeinflussen kann, Camel dazu veranlassen, an einem Ort seiner Wahl eine Datei mit den Rechten 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 Verlust der Integrität dieser Datei hinaus eskalieren. Die Option downloadFileName ist ein gewöhnlicher Consumer-Parameter und trägt keine Sicherheitskennzeichnung, sodass den Benutzern nichts signalisierte, dass ihr Wert nicht als Eindämmungsgrenze durchgesetzt wurde. Der Fehler betrifft ausschließlich den Consumer; der Producer hat keine Senke zum Herunterladen in eine Datei. Die anderen Datei-Download-Consumer von Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files und die Azure-Storage-Download-Pfade - haben ihre lokalen Downloads bereits mithilfe einer Pfadsegment-Grenzprüfung auf das konfigurierte Verzeichnis beschränkt; camel-google-storage war die verbleibende Objektstore-Download-Senke, die von dieser Arbeit nicht abgedeckt war. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Benutzern im 4.14.x-LTS-Release-Stream wird empfohlen, auf 4.14.9 zu aktualisieren. Benutzern im 4.18.x-Release-Stream wird empfohlen, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort aktualisiert werden können, setzen Sie die Filteroption auf einen regulären Ausdruck, der nur einfache einsegmentige Objektnamen akzeptiert, sodass jeder Name, der einen Pfadtrenner oder ein übergeordnetes Verzeichnissegment enthält, ausgeschlossen wird, bevor ein Exchange erstellt wird. Beachten Sie, dass bei nicht gesetzter Option keinerlei Filterung angewendet wird und dass der Ausdruck gegen den gesamten Objektnamen abgeglichen wird. Alternativ können Sie downloadFileName einen expliziten Ausdruck geben, der den Remote-Pfad nicht durchschleust, beispielsweise einen, der auf ${file:onlyname} basiert statt auf dem impliziten ${file:name}. Beachten Sie dabei, dass ein downloadFileName, das einen Ausdruck enthält, als vom Routenautor kontrolliert behandelt wird und nicht von der in der Korrektur hinzugefügten Eindämmungsprüfung abgedeckt ist. Zur Verteidigung in der Tiefe (Defense in Depth) behandeln Sie die Objektnamen in jedem extern beschreibbaren Bucket als nicht vertrauenswürdige Eingabe und leiten Sie keine lokalen Dateisystempfade daraus ab.