CVE-2026-79983
Apache Camel: camel-ftp löste den entfernten Pfad einer abgerufenen Datei aus dem im Server-Verzeichnislisting gemeldeten Namen auf, ohne ihn auf das abgerufene Verzeichnis zu beschränken, sodass ein Listing-Eintrag mit Traversal-Segmenten nach außerhalb verschoben werden konnte
- Veröffentlicht
- 19.10.2026
- Aktualisiert
- 19.10.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 17.10.2026
Primäres CVSS
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:NZusammenfassung
Schwachstelle „Improper Limitation of a Pathname to a Restricted Directory“ („Path Traversal“) in der Apache-Camel-FTP-Komponente. Dieses Problem betrifft Apache Camel: von 4.0.0 bis vor 4.18.5, von 4.19.0 bis vor 4.22.1. Die Camel-Remote-File-Consumer pollen ein Verzeichnis auf einem Remote-Server 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 keine lexikalische Normalisierung und keine Prüfung durch, ob das Ergebnis innerhalb des gepollten Verzeichnisses blieb, und der resultierende Pfad wurde zum Operanden für jede nachfolgende Remote-Operation auf der Datei: Abruf (FtpOperations.retrieveFile / SftpOperations, erreicht aus GenericFileConsumer, wobei 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 Polling-Verzeichnisses aufgelöst, wodurch Camel Dateien außerhalb davon 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 On-Path-Angreifer eine LIST-Antwort umschreiben kann, ohne über Anmeldedaten zu verfügen; 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 Disposition-Optionen, die alle verbreitet sind. Die Flucht aus dem Verzeichnis, das Camel zum Pollen konfiguriert wurde, ist unbedingt möglich, während die Flucht aus der Kontogrenze des Servers selbst 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 auch Consumer-Downloads in das lokale Arbeitsverzeichnis – sie beschränkte jedoch diesen Remote-Operanden nicht, sodass Name und Beschreibung eine Grenze behaupteten, die hier nicht durchgesetzt wurde. Derselbe Einstiegspunkt war bereits auf der lokalen Seite erkannt worden: Der Download-Pfad über localWorkDirectory wurde so beschränkt, dass ein Remote-Dateiname mit Parent-Directory-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 die Schemata ftp, ftps und sftp bereit, die alle betroffen sind. Der Melder demonstrierte das Problem durchgängig gegen einen ftp-Endpunkt, indem er eine Camel-Route mit einem bösartigen Server betrieb, dessen LIST-Antwort eine Datei außerhalb des gepollten Verzeichnisses benannte. 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.
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.