CVE-2026-79986
Apache Camel: camel-azure-files löste den entfernten Pfad einer abgefragten Datei aus dem im Server-Verzeichnislisting gemeldeten Namen auf, ohne ihn auf das abgefragte Verzeichnis zu beschränken, sodass ein Listing-Eintrag mit Traversal-Segmenten außerhalb verschoben werden konnte
- Veröffentlicht
- 19.10.2026
- Aktualisiert
- 20.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 durch unzulässige Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis („Path Traversal") in der Apache-Camel-Komponente Azure Files. Dieses Problem betrifft Apache Camel: von 4.0.0 vor 4.18.5, von 4.19.0 vor 4.22.1. Die Remote-File-Consumer von Camel pollen ein Verzeichnis auf einem entfernten Server und bilden den absoluten entfernten Pfad jeder Datei, indem sie das konfigurierte Verzeichnis mit dem im Verzeichnislisting des Servers gemeldeten Dateinamen verketten. Diese Verkettung (FtpUtils.absoluteFilePath und GenericFileConsumer) wandte keine lexikalische Normalisierung und keine Prüfung an, ob das Ergebnis innerhalb des gepollten Verzeichnisses blieb, und der resultierende Pfad wurde zum Operanden für jede nachfolgende entfernte Operation auf der Datei: Abruf (FtpOperations.retrieveFile / SftpOperations, erreicht von GenericFileConsumer, wobei der Abrufname wörtlich aus GenericFile.getAbsoluteFilePath übernommen wird), Löschung bei delete=true (GenericFileDeleteProcessStrategy) und Umbenennung bei konfiguriertem move, preMove, moveFailed oder readLock=rename (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 entfernten Server geliefert, und der FTP-Kontrollkanal bietet überhaupt keinen Integritätsschutz, sodass ein On-Path-Angreifer eine LIST-Antwort ohne jegliche Anmeldedaten umschreiben kann; ein kompromittierter, bösartiger oder Multi-Tenant-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 zu pollen konfiguriert war, ist bedingungslos, 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 dokumentiert ist als Beschränkung von Camel auf das Startverzeichnis und standardmäßig aktiviert ist, regelte Producer-Schreibvorgänge und seit der Containment-Arbeit für localWorkDirectory auch Consumer-Downloads in das lokale Arbeitsverzeichnis – sie beschränkte jedoch diesen entfernten Operanden nicht, 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 entfernter Dateiname mit Übergeordnetenverzeichnis-Segmenten nicht außerhalb des lokalen Arbeitsverzeichnisses aufgelöst werden konnte. Der entfernte Operand war die verbleibende Hälfte dieser Angriffsfläche. Dieses Artefakt stellt das Schema azure-files bereit. Sein Consumer leitet von derselben Basisklasse RemoteFileConsumer ab und setzte den entfernten Pfad über einen einfachen Verkettungshelfer zusammen, sodass er dieselbe unbeschränkte Auflösung erbte. Um ihn zu erreichen, ist ein Listing-Name erforderlich, der kein einzelnes Pfadsegment ist, was der Azure Files REST-Dienst normalerweise nicht zurückgibt; die Exposition wurde auf derselben Grundlage wie bei den anderen Remote-File-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 des Release-Streams 4.22.x sollten auf 4.22.1 aktualisieren. Benutzer des LTS-Release-Streams 4.18.x sollten auf 4.18.5 aktualisieren. Der Stream 4.14.x hat das Ende seiner Lebensdauer 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.