CVE-2026-79985

Zusammenfassung

Schwachstelle durch unzureichende Einschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis („Path Traversal“) in der Apache Camel SMB-Komponente. Dieses Problem betrifft Apache Camel: von 4.2.0 vor 4.18.5, von 4.19.0 vor 4.22.1. Die Remote-Datei-Consumer von Camel fragen ein Verzeichnis auf einem Remote-Server ab und bilden den absoluten Remote-Pfad jeder Datei, indem sie das konfigurierte Verzeichnis mit dem im Verzeichnislisting des Servers gemeldeten Dateinamen verketten. Diese Verkettung (FtpUtils.absoluteFilePath und GenericFileConsumer) führte weder eine lexikalische Normalisierung noch eine Prüfung durch, ob das Ergebnis innerhalb des abgefragten Verzeichnisses blieb, und der resultierende Pfad wurde zum Operanden für jede nachfolgende Remote-Operation auf der Datei: Abruf (FtpOperations.retrieveFile / SftpOperations, erreicht von GenericFileConsumer, wo der Abrufname wörtlich aus GenericFile.getAbsoluteFilePath übernommen wird), Löschung bei delete=true (GenericFileDeleteProcessStrategy) und Umbenennung, wenn move, preMove, moveFailed oder readLock=rename konfiguriert ist (GenericFileProcessStrategySupport und GenericFileRenameExclusiveReadLockStrategy). Weder isValidFile noch isMatched führten eine Containment-Prüfung durch. Ein Listing-Eintrag, der kein einzelnes Pfadsegment ist, wurde daher zu einem Pfad außerhalb des konfigurierten Abfrageverzeichnisses aufgelöst, wodurch Camel Dateien außerhalb dieses Verzeichnisses mit den eigenen Anmeldedaten des Endpunkts las, löschte oder umbenannte. Ein Listing-Name ist keine routenkontrollierte Datenquelle. Er wird vom Remote-Server geliefert, und der FTP-Kontrollkanal bietet überhaupt keinen Integritätsschutz, sodass ein Angreifer auf dem Übertragungsweg eine LIST-Antwort ohne jegliche Anmeldedaten umschreiben kann; ein kompromittierter, bösartiger oder mandantenfähiger Server oder ein Server, der auf einem virtuellen Dateisystem basiert, kann einen solchen Namen direkt ausgeben. Der Abruf ist in einer Standard-Consumer-Konfiguration erreichbar, da die Remote-Consumer jede gelistete Datei herunterladen; Löschung und Umbenennung erfordern zusätzlich eine der oben genannten Dispositionsoptionen, die alle verbreitet sind. Die Flucht aus dem Verzeichnis, das Camel zum Abfragen konfiguriert wurde, ist unbedingt möglich, während die Flucht aus der eigenen Kontogrenze des Servers zusätzlich davon abhängt, ob dieser Server das Konto einschränkt. Die Option jailStartingDirectory, die laut Dokumentation Camel auf das Startverzeichnis beschränkt und standardmäßig aktiviert ist, regelte Producer-Schreibvorgänge und – seit der Containment-Arbeit am localWorkDirectory – Consumer-Downloads in das lokale Arbeitsverzeichnis, doch sie schränkte diesen Remote-Operanden nicht ein, sodass ihr Name und ihre Beschreibung eine Grenze beanspruchten, die hier nicht durchgesetzt wurde. Derselbe Einstiegspunkt war bereits auf der lokalen Seite erkannt worden: Der Download-Pfad von localWorkDirectory wurde so eingeschränkt, dass ein Remote-Dateiname mit Übergeordneten-Verzeichnis-Segmenten nicht außerhalb des lokalen Arbeitsverzeichnisses aufgelöst werden konnte. Der Remote-Operand war die verbleibende Hälfte dieser Angriffsfläche. Dieses Artefakt stellt das smb-Schema bereit. Sein Consumer durchläuft das Share-Listing eigenständig statt über RemoteFileConsumer und überspringt nur die exakten Einträge „.“ und „..“, sodass ein Name, der Traversal-Segmente in irgendeiner anderen Form enthält, ungeprüft verkettet wurde. Um dies zu erreichen, ist ein Server erforderlich, der einen Listing-Namen ausgibt, der kein einzelnes Pfadsegment ist, was eine konforme SMB2-Implementierung nicht tut; die Exposition wurde auf derselben Grundlage wie bei den anderen Remote-Datei-Consumern korrigiert und nicht aufgrund eines nachgewiesenen Proof of Concept gegen dieses Schema. Führen Sie ein Upgrade auf Apache Camel 4.23.0 durch, das das Problem behebt. Benutzer im Release-Stream 4.22.x sollten auf 4.22.1 aktualisieren. Benutzer im LTS-Release-Stream 4.18.x sollten auf 4.18.5 aktualisieren. Der Stream 4.14.x hat das End-of-Life erreicht und erhält diesen Fix nicht; Benutzer sollten auf einen unterstützten Release-Stream wechseln.