CVE-2026-66907

Riepilogo

Vulnerabilità di path traversal relativo nel componente Google Storage di Apache Camel. Questo problema riguarda Apache Camel: dalla versione 4.0.0 fino alla 4.14.9 esclusa, dalla 4.15.0 fino alla 4.18.4 esclusa, dalla 4.19.0 fino alla 4.22.0 esclusa. Il consumer camel-google-storage scarica gli oggetti di Google Cloud Storage nel filesystem locale quando è impostata l'opzione downloadFileName. Tale opzione è documentata come una cartella o un nome di file e, quando il suo valore non contiene token di espressione, il consumer costruisce la destinazione locale aggiungendo il nome dell'oggetto: evaluateFileExpression imposta l'header file-name dell'Exchange al nome dell'oggetto remoto e valuta downloadFileName + "/${file:name}". Il token ${file:name} restituisce l'header file-name così com'è, a differenza di ${file:onlyname}, che vi applica FileUtil.stripPath. La stringa risultante veniva passata direttamente a new File(result) e a blob.downloadTo(file.toPath()) senza normalizzazione lessicale e senza verificare che la destinazione rimanesse all'interno della directory configurata. Il nome dell'oggetto non è un dato controllato dalla route: il consumer elenca il bucket, itera ogni blob restituito e crea uno scambio (exchange) per ogni oggetto a partire da blob.getBlobId().getName() così com'è, e l'opzione filter che potrebbe limitare 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 e elenca esattamente come scritte, senza canonicalizzazione lato server, e una barra obliqua è solo una convenzione di visualizzazione per pseudo-directory; pertanto una chiave contenente segmenti di directory padre sopravvive intatta al round-trip. Un nome di oggetto contenente tali segmenti risolveva quindi a una posizione esterna alla directory downloadFileName configurata, consentendo a chiunque fosse in grado di influenzare i nomi presenti nel bucket consumato di far creare o sovrascrivere a Camel un file in una posizione a propria scelta, con i privilegi del processo Camel. A seconda di ciò su cui il processo può scrivere, la sovrascrittura di un file all'esterno della directory di download può portare a conseguenze più gravi della semplice perdita di integrità di quel file. L'opzione downloadFileName è un normale parametro del consumer e non porta alcun indicatore di sicurezza, quindi nulla segnalava agli utenti che il suo valore non veniva applicato come confine di contenimento. Il difetto riguarda solo il consumer; il producer non ha un sink di download su file. Gli altri consumer di download di file di Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files e i percorsi di download di Azure Storage - limitavano già i download locali alla directory configurata mediante un controllo di confine sui segmenti del percorso; camel-google-storage era il rimanente sink di download per object store non coperto da tale intervento. Si consiglia agli utenti di aggiornare alla versione 4.22.0, che risolve il problema. Se gli utenti si trovano sul ramo di release LTS 4.14.x, si suggerisce di aggiornare alla 4.14.9. Se gli utenti si trovano sul ramo di release 4.18.x, si suggerisce di aggiornare alla 4.18.4. Per le distribuzioni che non possono aggiornare immediatamente, impostare l'opzione filter su un'espressione regolare che accetti solo semplici nomi di oggetto a segmento singolo, così che qualsiasi nome contenente un separatore di percorso o un segmento di directory padre venga escluso prima della creazione di un exchange; si noti che non viene applicato alcun filtro quando l'opzione non è impostata e che l'espressione viene confrontata con l'intero nome dell'oggetto. In alternativa, assegnare a downloadFileName un'espressione esplicita che non propaghi il percorso remoto, ad esempio una basata su ${file:onlyname} invece del ${file:name} implicito, tenendo presente che un downloadFileName contenente un'espressione è considerato controllato dall'autore della route e non è coperto dal controllo di contenimento aggiunto nella correzione. Come difesa in profondità, trattare i nomi degli oggetti in qualsiasi bucket scrivibile esternamente come input non attendibile e non derivare da essi percorsi del filesystem locale.