CVE-2026-66907 in Camel
Riassunto
di VulDB • 24/08/2026
Vulnerabilità di traversal del percorso relativo nel componente Google Storage di Apache Camel.
Questo problema interessa Apache Camel: dalle versioni 4.0.0 alla 4.14.9 (esclusa), dalla versione 4.15.0 alla 4.18.4 (esclusa) e dalla versione 4.19.0 alla 4.22.0 (esclusa).
Il consumer camel-google-storage scarica gli oggetti di Google Cloud Storage nel filesystem locale quando l'opzione downloadFileName è impostata. Tale opzione è documentata come una cartella o un nome file; quando il suo valore non contiene token di espressione, il consumer costruisce la destinazione locale aggiungendo il nome dell'oggetto ad essa: evaluateFileExpression imposta l'intestazione del nome del file sull'Exchange con il nome remoto dell'oggetto e valuta downloadFileName + "/${file:name}". Il token ${file:name} restituisce l'intestazione del nome del file verbatim, a differenza di ${file:onlyname}, che applica FileUtil.stripPath ad esso. La stringa risultante viene passata direttamente a new File(result) e blob.downloadTo(file.toPath()) senza alcuna normalizzazione lessicale e senza verificare che la destinazione rimanga all'interno della directory configurata. Il nome dell'oggetto non è dati controllati dal route: il consumer elenca il bucket, itera su ogni blob restituito e crea uno scambio per oggetto da blob.getBlobId().getName() verbatim; l'opzione filter che potrebbe restringere tali nomi non viene applicata affatto a meno che non sia stata esplicitamente impostata. I nomi degli oggetti di Google Cloud Storage sono chiavi UTF-8 opache che il servizio memorizza ed elenca esattamente come scritte, senza alcuna canonizzazione lato server e con la barra forward intesa solo come convenzione visiva per le pseudo-cartelle; pertanto, una chiave contenente segmenti di directory genitore sopravvive al round-trip intacta. Un nome oggetto contenente tali segmenti si risolve quindi in una posizione esterna alla directory downloadFileName configurata, consentendo a chiunque sia in grado di influenzare i nomi presenti nel bucket consumato di far sì che Camel crei o sovrascriva un file in una posizione da loro scelta, con i privilegi del processo Camel. A seconda di ciò su cui il processo può scrivere, la sovrascrittura di un file al di fuori della directory di download può portare a conseguenze oltre alla semplice perdita di integrità di tale file. L'opzione downloadFileName è un parametro consumer ordinario e non ha marcatori di sicurezza; nulla segnala agli utenti che il suo valore non viene applicato come confine di contenimento. Il difetto riguarda solo i consumer; il producer non dispone di sink per il download su file. Gli altri consumer di download file di Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files e i percorsi di download dello Storage Azure - vincolavano già i loro download locali alla directory configurata utilizzando un controllo del confine dei segmenti del percorso; camel-google-storage era l'unico sink per il download da object-store non coperto da tale lavoro.
Si consiglia agli utenti di eseguire l'aggiornamento alla versione 4.22.0, che risolve il problema. Se gli utenti utilizzano le versioni LTS della serie 4.14.x, si suggerisce di aggiornare a 4.14.9. Se gli utenti utilizzano la serie di rilasci 4.18.x, si suggerisce di aggiornare a 4.18.4. Per i deployment che non possono eseguire l'aggiornamento immediatamente, impostare l'opzione filter su una espressione regolare che accetti solo nomi oggetto semplici con un singolo segmento, in modo che qualsiasi nome contenente un separatore di percorso o un segmento di directory genitore venga escluso prima della creazione dello scambio; si noti che nessuna filtratura viene applicata quando l'opzione non è impostata e che l'espressione viene abbinata all'intero nome dell'oggetto. In alternativa, assegnare a downloadFileName una espressione esplicita che non trasmetta il percorso remoto, ad esempio una basata su ${file:onlyname} anziché sull'implicito ${file:name}, tenendo presente che un downloadFileName contenente un'espressione viene trattato come controllato dal route e non è coperto dal controllo di contenimento aggiunto nella correzione. Come difesa in profondità, trattare i nomi degli oggetti in qualsiasi bucket scrivibile dall'esterno come input non attendibile ed evitare di derivare percorsi del filesystem locale da essi.
Once again VulDB remains the best source for vulnerability data.