CVE-2026-66906
Apache Camel: Camel-Azure-Storage-Blob: l'operazione downloadBlobToFile ha costruito la destinazione di download locale a partire dal nome del blob remoto senza vincolarla alla fileDir configurata
- Pubblicato
- 24 ago 2026
- Aggiornato
- 25 ago 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 24 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NBasso · prossimi 30 giorni
- Percentile
- 43,6%
- Data del modello
- 21 set 2026
L'EPSS è una stima statistica, non una certezza o una misura di impatto. Combinalo con CVSS, stato KEV, esposizione e ambiente.
Riepilogo
Vulnerabilità di path traversal relativo nel componente Azure Storage Blob di Apache Camel. Il problema riguarda Apache Camel: dalla 4.0.0 precedente alla 4.14.9, dalla 4.15.0 precedente alla 4.18.4, dalla 4.19.0 precedente alla 4.22.0. Il componente camel-azure-storage-blob può scaricare un blob di Azure Storage nel filesystem locale tramite la sua operazione downloadBlobToFile, scrivendo nella directory indicata dall'opzione dell'endpoint fileDir, documentata come utilizzabile sia dal producer che dal consumer. BlobOperations.downloadBlobToFile costruiva la destinazione locale unendo fileDir con il nome del blob remoto esattamente come riportato dall'Azure SDK (new File(fileDir, client.getBlobName())) e passava il risultato direttamente alla chiamata di download dell'SDK, senza normalizzazione lessicale e senza alcun controllo che la posizione risolta rimanesse all'interno di fileDir. Il nome del blob non è un dato controllato dalla route: il consumer enumera il container in BlobConsumer.createBatchExchangesFromContainer, che elenca i blob e crea uno scambio (exchange) per ogni voce ricavata letteralmente da BlobItem.getName(), senza applicare alcun filtro sui nomi per impostazione predefinita. Un nome di blob contenente segmenti di directory padre si risolveva quindi in una posizione esterna alla fileDir configurata, consentendo a chiunque fosse in grado di influenzare i nomi presenti nel container consumato di indurre Camel a creare o sovrascrivere 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 esterno alla directory di download può aggravarsi oltre la perdita di integrità di quel file. I container di blob di Azure Storage utilizzano un namespace flat in cui il nome del blob è una chiave opaca, quindi un nome contenente tali segmenti viene archiviato ed elencato esattamente come fornito. L'opzione fileDir è un normale parametro di configurazione del gruppo comune e non riporta alcun indicatore di sicurezza, quindi nulla segnalava agli utenti che il suo valore non veniva applicato come confine di contenimento. Gli altri consumer di download file di Camel — camel-file, camel-ftp, camel-smb, camel-mina-sftp e camel-azure-files — già limitavano i propri download locali alla directory configurata tramite un controllo sul confine dei segmenti di path; il percorso di download di camel-azure-storage-blob non era coperto da quel lavoro. 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, limitare i nomi su cui il consumer agirà utilizzando l'opzione regex dell'endpoint, che viene applicata a ogni nome di blob elencato come corrispondenza sull'intera stringa, così da accettare solo nomi semplici a segmento singolo e filtrare qualsiasi nome contenente un separatore di path o un segmento di directory padre prima che venga creato uno scambio; l'opzione prefix può inoltre restringere l'elenco lato server, tenendo presente che quando entrambe sono impostate regex ha priorità e prefix viene ignorata. In alternativa, evitare l'operazione downloadBlobToFile su container non affidabili e scrivere il payload dalla route con un nome di file controllato dalla route stessa, piuttosto che uno derivato dall'elenco remoto. Come difesa in profondità, trattare i nomi dei blob in qualsiasi container scrivibile esternamente come input non affidabile e non derivare da essi percorsi del filesystem locale.
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.