CVE-2026-60093
Apache Camel: Camel-Azure-Storage-DataLake: Die downloadToFile-Operation erstellte das lokale Download-Ziel aus dem Remote-Pfadnamen, ohne es auf das konfigurierte fileDir zu beschränken.
- Veröffentlicht
- 24.08.2026
- Aktualisiert
- 25.08.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 24.08.2026
Primäres CVSS
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NNiedrig · nächste 30 Tage
- Perzentil
- 13,7 %
- Modelldatum
- 15.10.2026
EPSS ist eine statistische Schätzung, keine Gewissheit oder ein Maß für die Auswirkung. Kombinieren Sie es mit CVSS, KEV-Status, Belichtung und Ihrer Umgebung.
Zusammenfassung
Schwachstelle durch relatives Pfad-Traversal in der Apache-Camel-Komponente Azure-Storage-Datalake Diese Schwachstelle betrifft Apache Camel: Versionen von 4.0.0 bis vor 4.14.9, von 4.15.0 bis vor 4.18.4 und von 4.19.0 bis vor 4.22.0. Die Komponente camel-azure-storage-datalake kann über ihre Operation downloadToFile eine Datei aus Azure Data Lake Storage Gen2 in das lokale Dateisystem herunterladen und dabei in das Verzeichnis schreiben, das durch die Endpoint-Option fileDir benannt ist. DataLakeFileOperations.downloadToFile baute das lokale Ziel, indem es fileDir mit dem Remote-Pfadnamen genau so verknüpfte, wie ihn das Azure SDK gemeldet hatte (new File(fileDir, fileClientWrapper.getFileName())), und übergab das Ergebnis direkt an den SDK-Downloadaufruf – ohne lexikalische Normalisierung und ohne Prüfung, dass der aufgelöste Speicherort innerhalb von fileDir blieb. Der Remote-Name unterliegt nicht der Kontrolle der Route: Der Consumer enumeriert das Dateisystem in DataLakeConsumer.createBatchExchangesFromPath, das die Pfade auflistet und pro Eintrag wörtlich einen Exchange aus PathItem.getName() erstellt, ohne standardmäßig eine Namensfilterung anzuwenden. Ein Pfadname, der übergeordnete Verzeichnissegmente enthält, wurde daher in einen Speicherort außerhalb des konfigurierten fileDir aufgelöst. Dadurch konnte jeder, der die im konsumierten Data-Lake-Dateisystem vorhandenen Namen beeinflussen kann, Camel dazu veranlassen, eine Datei an einem Ort seiner Wahl 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 bloßen Verlust der Integrität dieser Datei hinaus eskalieren. Die Option fileDir ist ein gewöhnlicher Konfigurationsparameter der Gruppe „common“ und trägt keine Sicherheitskennzeichnung, sodass für Benutzer nichts darauf hindeutete, dass ihr Wert nicht als Eindämmungsgrenze durchgesetzt wird. 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-datalake war von dieser Arbeit nicht abgedeckt. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer den 4.14.x-LTS-Release-Stream verwenden, wird empfohlen, auf 4.14.9 zu aktualisieren. Wenn Benutzer den 4.18.x-Release-Stream verwenden, wird empfohlen, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort aktualisiert werden können, sollten die Namen, auf die der Consumer reagiert, mithilfe der Regex-Endpointoption eingeschränkt werden. Diese wird auf jeden aufgelisteten Pfadnamen als Vollstring-Übereinstimmung angewendet, sodass nur einfache Namen mit einem einzelnen Segment akzeptiert werden und jeder Name, der ein Pfadtrennzeichen oder ein übergeordnetes Verzeichnissegment enthält, herausgefiltert wird, bevor ein Exchange erstellt wird. Alternativ sollte die Operation downloadToFile auf nicht vertrauenswürdigen Dateisystemen vermieden werden und die Nutzlast aus der Route unter einem Dateinamen geschrieben werden, den die Route selbst kontrolliert, anstatt einen aus der Remote-Auflistung zu übernehmen. Als Defense-in-Depth-Maßnahme sollten die Objektnamen in jedem extern beschreibbaren Data-Lake-Dateisystem als nicht vertrauenswürdige Eingabe behandelt werden, und es sollten keine lokalen Dateisystempfade von ihnen abgeleitet werden.
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.