CVE-2026-66907 in Camel
Sumário
de VulDB • 24/08/2026
Vulnerabilidade de travessia de caminho relativo no componente Google Storage do Apache Camel.
Este problema afeta o Apache Camel: da versão 4.0.0 até antes da 4.14.9, da 4.15.0 até antes da 4.18.4 e da 4.19.0 até antes da 4.22.0.
O consumidor camel-google-storage baixa objetos do Google Cloud Storage para o sistema de arquivos local quando a opção downloadFileName está definida. Essa opção é documentada como uma pasta ou um nome de arquivo, e quando seu valor não contém token de expressão, o consumidor constrói o destino local anexando o nome do objeto a ele: evaluateFileExpression define o cabeçalho file-name do Exchange para o nome do objeto remoto e avalia downloadFileName + "/${file:name}". O token ${file:name} retorna o cabeçalho file-name literalmente, ao contrário de ${file:onlyname}, que aplica FileUtil.stripPath a ele. A string resultante foi passada diretamente para new File(result) e blob.downloadTo(file.toPath()) sem normalização léxica e sem verificação de que o destino permanecesse dentro do diretório configurado. O nome do objeto não é dados controlados pela rota: o consumidor lista o bucket, itera cada blob retornado e cria um exchange por objeto a partir de blob.getBlobId().getName() literalmente, e a opção filter que poderia restringir esses nomes não é aplicada em absoluto, a menos que tenha sido definida explicitamente. Os nomes dos objetos do Google Cloud Storage são chaves UTF-8 opacas que o serviço armazena e lista exatamente como escritas, sem canonicização no lado do servidor, e uma barra forward slash (/) é apenas uma convenção de exibição para pseudo-diretórios; portanto, um nome contendo segmentos de diretório pai sobrevive à ida e volta intacto. Um nome de objeto contendo tais segmentos resolve-se, portanto, para um local fora do diretorio downloadFileName configurado, permitindo que qualquer pessoa capaz de influenciar os nomes presentes no bucket consumido faça com que o Camel crie ou sobrescreva um arquivo em um local de sua escolha, com as permissões do processo do Camel. Dependendo do que o processo pode gravar, a sobreescrição de um arquivo fora do diretório de download pode escalar além da perda de integridade desse arquivo. A opção downloadFileName é um parâmetro comum de consumidor e não possui marcador de segurança; portanto, nada sinalizou aos usuários que seu valor não estava sendo aplicado como uma fronteira de contenção. O defeito é apenas no consumidor; o produtor não tem um sink de download para arquivo. Os outros consumidores de download de arquivos do Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files e os caminhos de download do Azure Storage - já restringiam seus downloads locais ao diretório configurado usando uma verificação de fronteira de segmento de caminho; o camel-google-storage era o único sink de download de armazenamento de objetos não coberto por esse trabalho.
Recomenda-se que os usuários atualizem para a versão 4.22.0, que corrige o problema. Se os usuários estiverem na linha de lançamentos LTS da série 4.14.x, sugere-se que atualizem para a 4.14.9. Se os usuários estiverem na linha de lançamentos da série 4.18.x, sugere-se que atualizem para a 4.18.4. Para implantações que não podem fazer upgrade imediatamente, defina a opção filter como uma expressão regular que aceite apenas nomes de objetos simples com um único segmento, de modo que qualquer nome contendo separador de caminho ou segmento de diretório pai seja excluído antes da criação do exchange; observe que nenhuma filtragem é aplicada quando a opção não está definida e que a expressão é correspondida contra o nome completo do objeto. Alternativamente, atribua à downloadFileName uma expressão explícita que não transmita o caminho remoto, por exemplo, uma construída com base em ${file:onlyname} em vez da implícita ${file:name}, lembrando-se de que um downloadFileName contendo uma expressão é tratado como controlado pela rota e não está coberto pela verificação de contenção adicionada na correção. Como defesa em profundidade, trate os nomes dos objetos em qualquer bucket gravável externamente como entrada não confiável e não derive caminhos do sistema de arquivos local a partir deles.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.