CVE-2026-66906
Apache Camel: Camel-Azure-Storage-Blob: a operação downloadBlobToFile construiu o destino de download local a partir do nome do blob remoto sem restringi-lo ao fileDir configurado
- Publicado
- 24 de ago. de 2026
- Atualizado
- 25 de ago. de 2026
- Atribuindo CNA
- apache
- Evidência observada
- 24 de ago. de 2026
CVSS primário
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NBaixo · próximos 30 dias
- Percentil
- 43,6%
- Data do modelo
- 21 de set. de 2026
EPSS é uma estimativa estatística, não uma certeza ou uma medida de impacto. Combine-o com CVSS, status KEV, exposição e seu ambiente.
Resumo
Vulnerabilidade de travessia de caminho relativo no componente Apache Camel Azure Storage Blob. Este problema afeta o Apache Camel: de 4.0.0 antes de 4.14.9, de 4.15.0 antes de 4.18.4, de 4.19.0 antes de 4.22.0. O componente camel-azure-storage-blob pode descarregar um blob do Azure Storage para o sistema de ficheiros local através da operação downloadBlobToFile, escrevendo no diretório nomeado pela opção de endpoint fileDir, que está documentada como utilizável tanto pelo produtor como pelo consumidor. BlobOperations.downloadBlobToFile construía o destino local juntando fileDir com o nome do blob remoto exatamente como o Azure SDK o reportava (new File(fileDir, client.getBlobName())) e passava o resultado diretamente para a chamada de download do SDK, sem normalização lexical e sem verificação de que a localização resolvida permanecia dentro de fileDir. O nome do blob não são dados controlados pela rota: o consumidor enumera o contentor em BlobConsumer.createBatchExchangesFromContainer, que lista os blobs e cria uma troca por cada entrada a partir de BlobItem.getName() verbatim, sem aplicar qualquer filtragem de nomes por predefinição. Um nome de blob contendo segmentos de diretório-pai resolvia, portanto, para uma localização fora do fileDir configurado, permitindo que qualquer pessoa capaz de influenciar os nomes presentes no contentor consumido fizesse o Camel criar ou sobrescrever um ficheiro numa localização à sua escolha, com os privilégios do processo Camel. Dependendo do que o processo pode escrever, sobrescrever um ficheiro fora do diretório de descarga pode escalar para além da perda de integridade desse ficheiro. Os contentores de blobs do Azure Storage utilizam um espaço de nomes plano no qual o nome do blob é uma chave opaca, pelo que um nome que contenha tais segmentos é armazenado e listado tal como foi fornecido. A opção fileDir é um parâmetro de configuração comum do grupo geral e não possui qualquer marcação de segurança, pelo que nada sinalizava aos utilizadores que o seu valor não estava a ser imposto como limite de contenção. Os outros consumidores de descarga de ficheiros do Camel — camel-file, camel-ftp, camel-smb, camel-mina-sftp e camel-azure-files — já restringiam as suas descargas locais ao diretório configurado através de uma verificação de limite de segmentos de caminho; o caminho de descarga do camel-azure-storage-blob não era abrangido por esse trabalho. Recomenda-se aos utilizadores que atualizem para a versão 4.22.0, que corrige o problema. Se os utilizadores estiverem no stream de lançamentos LTS 4.14.x, sugere-se que atualizem para 4.14.9. Se os utilizadores estiverem no stream de lançamentos 4.18.x, sugere-se que atualizem para 4.18.4. Para implementações que não possam atualizar imediatamente, restrinja os nomes sobre os quais o consumidor atuará utilizando a opção de endpoint regex, que é aplicada a cada nome de blob listado como uma correspondência de string completa, de modo que apenas nomes simples de segmento único sejam aceites e qualquer nome que contenha um separador de caminho ou um segmento de diretório-pai seja filtrado antes de uma troca ser criada; a opção prefix pode adicionalmente estreitar a listagem no lado do servidor, observando que, quando ambas estão definidas, regex tem prioridade e prefix é ignorado. Em alternativa, evite a operação downloadBlobToFile em contentores não confiáveis e escreva o payload a partir da rota sob um nome de ficheiro que a própria rota controla, em vez de um nome obtido da listagem remota. Como defesa em profundidade, trate os nomes de blob em qualquer contentor gravável externamente como entrada não confiável e não derive caminhos de sistema de ficheiros locais a partir deles.
Uso responsável
Use informações de vulnerabilidade apenas em sistemas que você possui ou está autorizado a testar. O Kitploit vincula-se a metadados de pesquisa pública e não armazena código de exploração ou cargas maliciosas.