CVE-2026-79984

Published: Ott 19, 2026 Last Modified: Ott 20, 2026

ExploitDB:

Other exploit source:

Google Dorks:

HIGH 7,4

Source: [email protected]

Attack Vector: network

Attack Complexity: high

Privileges Required: none

User Interaction: none

Scope: unchanged

Confidentiality: high

Integrity: high

Availability: none

Description

AI Translation Available

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Mina SFTP component.

This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1.

The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint's own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel carries no integrity protection at all, so an on-path attacker can rewrite a LIST response without holding any credentials; a compromised, malicious or multi-tenant server, or a server backed by a virtual filesystem, can emit such a name directly. Retrieval is reachable in a default consumer configuration, since the remote consumers download every listed file; deletion and renaming additionally require one of the disposition options above, all of which are common. Escape from the directory Camel was configured to poll is unconditional, while escape from the server's own account boundary additionally depends on whether that server confines the account. The jailStartingDirectory option, which is documented as restricting Camel to the starting directory and is enabled by default, governed producer writes and, since the localWorkDirectory containment work, consumer downloads to the local work directory - but it did not constrain this remote operand, so its name and description claimed a boundary that was not enforced here. The same entry point had already been recognised on the local side: the localWorkDirectory download path was constrained so that a remote file name containing parent-directory segments could not resolve outside the local work directory. The remote operand was the remaining half of that surface. This artifact provides the mina-sftp scheme, an alternative SFTP implementation whose consumer derives from the same RemoteFileConsumer base class and therefore inherited the same unconstrained resolution.

Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does not receive this fix; users on it should move to a supported releases stream.

AI Generated Translation

Vulnerabilità di Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') nel componente Apache Camel Mina SFTP.

Questo problema riguarda Apache Camel: dalla versione 4.18.0 prima della 4.18.5, dalla 4.19.0 prima della 4.22.1.

I consumer remote-file di Camel interrogano una directory su un server remoto e costruiscono il percorso assoluto remoto di ogni file concatenando la directory configurata con il nome del file riportato nell'elenco della directory del server. Tale concatenazione (FtpUtils.absoluteFilePath e GenericFileConsumer) applicava nessuna normalizzazione lessicale e nessun controllo che il risultato rimanesse all’interno della directory interrogata, e il percorso risultante diventava l’operando per ogni successiva operazione remota sul file: recupero (FtpOperations.retrieveFile / SftpOperations, raggiunto da GenericFileConsumer dove il nome del retrieve viene preso letteralmente da GenericFile.getAbsoluteFilePath), eliminazione quando delete=true (GenericFileDeleteProcessStrategy), e rinomina quando move, preMove, moveFailed o readLock=rename sono configurati (GenericFileProcessStrategySupport e GenericFileRenameExclusiveReadLockStrategy). Né isValidFile né isMatched eseguivano alcun controllo di containment. Un entry di listing che non fosse un singolo segmento di percorso poteva quindi risolversi in un percorso al di fuori della directory di polling configurata, causando a Camel di leggere, eliminare o rinominare file al di fuori di essa usando le credenziali dell’endpoint. Un nome di listing non è dato controllato dalla route. È fornito dal server remoto, e il canale di controllo FTP non garantisce alcuna protezione di integrità, quindi un attaccante on-path può riscrivere una risposta LIST senza possedere credenziali; un server compromesso, malizioso o multi-tenant, o un server supportato da un filesystem virtuale, può emettere direttamente tale nome. Il recupero è raggiungibile in una configurazione di consumer predefinita, poiché i consumer remoti scaricano ogni file elencato; l’eliminazione e la rinomina richiedono inoltre una delle opzioni di disposizione sopra menzionate, tutte comuni. La fuga dalla directory su cui Camel era configurato per interrogare è incondizionata, mentre la fuga dal confine dell’account del server dipende anche dal fatto che il server limiti o meno l’account stesso. L’opzione jailStartingDirectory, documentata come limitante Camel alla directory di partenza ed abilitata di default, governava le scritture del producer e, poiché il lavoro di containment di localWorkDirectory, anche il download del consumer alla directory di lavoro locale — ma non limitava questo operando remoto, quindi il suo nome e descrizione affermavano un confine che qui non era applicato. Lo stesso punto di ingresso era già stato riconosciuto sul lato locale: il percorso di download di localWorkDirectory era limitato in modo che un nome di file remoto contenente segmenti di directory padre non potesse risolversi al di fuori della directory di lavoro locale. L’operando remoto rappresentava l’altra metà di quella superficie. Questo artefatto fornisce il mina-sftp scheme, un’implementazione SFTP alternativa il cui consumer deriva dalla stessa classe base RemoteFileConsumer e quindi eredita la stessa risoluzione non limitata.

Aggiornare ad Apache Camel 4.23.0, che risolve il problema. Gli utenti delle versioni della serie 4.22.x devono aggiornare alla 4.22.1. Gli utenti delle versioni LTS 4.18.x devono aggiornare alla 4.18.5. La serie 4.14.x ha raggiunto la fine del ciclo di vita e non riceve questa correzione; gli utenti di questa versione devono passare a una serie di release supportate.