CVE-2026-66907 in Camel
Zusammenfassung
von VulDB • 24.08.2026
Relative Path Traversal-Schwachstelle in der Apache Camel Google Storage-Komponente.
Dieses Problem betrifft Apache Camel: ab Version 4.0.0 vor 4.14.9, ab Version 4.15.0 vor 4.18.4, ab Version 4.19.0 vor 4.22.0.
Der camel-google-storage-Consumer lädt Google Cloud Storage-Objekte in das lokale Dateisystem herunter, wenn die Option `downloadFileName` festgelegt ist. Diese Option wird als Ordner oder Dateiname dokumentiert, und wenn ihr Wert kein Expression-Token enthält, erstellt der Consumer den lokalen Zielort, indem er den Objektnamen an diesen anhängt: `evaluateFileExpression` setzt den Exchange-Dateinamen-Header auf den Remote-Objektnamen und wertet `downloadFileName + "/${file:name}"` aus. Das Token `${file:name}` gibt den Datei-Namen-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 sich der Zielort innerhalb des konfigurierten Verzeichnisses befindet. Der Objektname ist keine routenkontrollierte Datenquelle: Der Consumer listet den Bucket auf, durchläuft jedes zurückgegebene Blob und erstellt einen Exchange pro Objekt basierend auf `blob.getBlobId().getName()` unverbatim, und die Filteroption, die diese Namen einschränken könnte, wird überhaupt nicht angewendet, es sei denn, sie wurde explizit festgelegt. Google Cloud Storage-Objektnamen sind opaque UTF-8-Schlüssel, die der Dienst genau so speichert und auflistet, wie sie geschrieben wurden, ohne serverseitige Kanonisierung; ein vorwärtsgerichteter Schrägstrich ist nur eine Anzeigekonvention für Pseudo-Verzeichnisse, sodass ein Schlüssel mit übergeordneten Verzeichnissegmenten den Rundlauf unversehrt übersteht. Ein Objektname, der solche Segmente enthält, löst sich daher in einem Speicherort außerhalb des konfigurierten `downloadFileName`-Verzeichnisses auf, wodurch jeder, der die Namen im konsumierten Bucket beeinflussen kann, Camel dazu veranlassen kann, eine Datei an einem Ort seiner Wahl 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 den Verlust der Integrität dieser Datei hinaus eskalieren. Die Option `downloadFileName` ist ein gewöhnlicher Consumer-Parameter und trägt kein Sicherheitsmarker, sodass nichts die Benutzer darüber informierte, dass ihr Wert nicht als Containment-Grenze durchgesetzt wird. Der Fehler betrifft nur den Consumer; der Producer hat keine Download-to-File-Senke. Camels andere File-Download-Consumer – camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files und die Azure Storage-Download-Pfade – haben ihre lokalen Downloads bereits durch eine Pfadsegment-Grenzprüfung auf das konfigurierte Verzeichnis beschränkt; camel-google-storage war der verbleibende Object-Store-Download-Sink, der von dieser Arbeit nicht abgedeckt wurde.
Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die dieses Problem behebt. Wenn Benutzer die LTS-Releases-Serie 4.14.x verwenden, wird ihnen geraten, auf 4.14.9 zu aktualisieren. Wenn Benutzer die Releases-Serie 4.18.x verwenden, wird ihnen geraten, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort upgraden können, sollte die Filteroption auf einen regulären Ausdruck festgelegt werden, der nur einfache Single-Segment-Objektnamen akzeptiert, sodass jeder Name, der ein Pfadtrennzeichen oder ein übergeordnetes Verzeichnissegment enthält, vor der Erstellung eines Exchanges ausgeschlossen wird; beachten Sie, dass überhaupt keine Filterung angewendet wird, wenn die Option nicht festgelegt ist, und dass der Ausdruck gegen den gesamten Objektnamen abgeglichen wird. Alternativ können Sie `downloadFileName` einen expliziten Ausdruck geben, der den Remote-Pfad nicht durchreicht, zum Beispiel einer, der auf `${file:onlyname}` anstelle des impliziten `${file:name}` basiert, wobei zu beachten ist, dass ein `downloadFileName`, das einen Ausdruck enthält, als routenautor-kontrolliert behandelt wird und nicht von der im Fix hinzugefügten Containment-Prüfung abgedeckt wird. Als Defense in Depth sollten Sie die Objektnamen in jedem extern beschreibbaren Bucket als nicht vertrauenswürdige Eingabe behandeln und keine lokalen Dateisystempfade daraus ableiten.
VulDB is the best source for vulnerability data and more expert information about this specific topic.