CVE-2026-79983
Apache Camel: camel-ftp risolveva il percorso remoto di un file sottoposto a polling a partire dal nome riportato nel listato della directory del server senza vincolarlo alla directory oggetto del polling, cosicché una voce del listato contenente segmenti di traversal poteva essere spostata all'esterno
- Pubblicato
- 19 ott 2026
- Aggiornato
- 20 ott 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 17 ott 2026
CVSS primario
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:NRiepilogo
Vulnerabilità di limitazione impropria di un pathname a una directory ristretta ('Path Traversal') nel componente FTP di Apache Camel. Questo problema interessa Apache Camel: dalla 4.0.0 alla 4.18.5 esclusa, dalla 4.19.0 alla 4.22.1 esclusa. I consumer remote-file di Camel eseguono il polling di una directory su un server remoto e costruiscono il percorso remoto assoluto di ciascun file concatenando la directory configurata con il nome del file riportato nel listing della directory del server. Tale concatenazione (FtpUtils.absoluteFilePath e GenericFileConsumer) non applicava alcuna normalizzazione lessicale né alcun controllo che il risultato rimanesse all'interno della directory sottoposta a polling, e il percorso risultante diventava l'operando per ogni successiva operazione remota sul file: recupero (FtpOperations.retrieveFile / SftpOperations, raggiunti da GenericFileConsumer dove il nome da recuperare è preso letteralmente da GenericFile.getAbsoluteFilePath), cancellazione quando delete=true (GenericFileDeleteProcessStrategy) e rinomina quando sono configurati move, preMove, moveFailed o readLock=rename (GenericFileProcessStrategySupport e GenericFileRenameExclusiveReadLockStrategy). Né isValidFile né isMatched eseguivano alcun controllo di contenimento. Una voce del listing che non è un singolo segmento di percorso si risolveva quindi in un percorso esterno alla directory di polling configurata, causando la lettura, cancellazione o rinomina di file al di fuori di essa da parte di Camel utilizzando le credenziali dell'endpoint stesso. Un nome nel listing non è un dato controllato dalla route. Esso è fornito dal server remoto, e il canale di controllo FTP non dispone di alcuna protezione dell'integrità, quindi un attaccante on-path può riscrivere una risposta LIST senza possedere alcuna credenziale; un server compromesso, malevolo o multi-tenant, o un server basato su un filesystem virtuale, può emettere direttamente tale nome. Il recupero è raggiungibile in una configurazione predefinita del consumer, poiché i consumer remoti scaricano ogni file elencato; la cancellazione e la rinomina richiedono inoltre una delle opzioni di disposizione sopra indicate, tutte comuni. L'evasione dalla directory che Camel era configurato per sottoporre a polling è incondizionata, mentre l'evasione dal confine dell'account del server dipende inoltre dal fatto che tale server confini l'account. L'opzione jailStartingDirectory, documentata come restrizione di Camel alla directory di partenza e abilitata per impostazione predefinita, governava le scritture del producer e, a seguito del lavoro sul contenimento di localWorkDirectory, i download dei consumer verso la directory di lavoro locale - ma non vincolava questo operando remoto, quindi il suo nome e la sua descrizione rivendicavano 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 stato vincolato affinché un nome di file remoto contenente segmenti di directory padre non potesse risolversi al di fuori della directory di lavoro locale. L'operando remoto era la metà rimanente di quella superficie. Questo artefatto fornisce gli schemi ftp, ftps e sftp, tutti interessati. Il segnalante ha dimostrato il problema end to end contro un endpoint ftp, pilotando una route Camel con un server malevolo la cui risposta LIST indicava un file esterno alla directory sottoposta a polling. Aggiornare ad Apache Camel 4.23.0, che corregge il problema. Gli utenti sul ramo delle release 4.22.x devono aggiornare alla 4.22.1. Gli utenti sul ramo delle release LTS 4.18.x devono aggiornare alla 4.18.5. Il ramo 4.14.x ha raggiunto l'end of life e non riceve questa correzione; gli utenti su di esso devono passare a un ramo di release supportato.
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.