CVE-2026-78163
Apache Camel: fonte de entrada de corpo de mensagem não validado no Camel-Docling permite Server-Side Request Forgery e divulgação de arquivos locais
- Publicado
- 19 de out. de 2026
- Atualizado
- 19 de out. de 2026
- Atribuindo CNA
- apache
- Evidência observada
- 17 de out. de 2026
CVSS primário
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NResumo
Vulnerabilidade de Server-Side Request Forgery (SSRF), Limitação Imprópria de um Nome de Caminho a um Diretório Restrito ('Path Traversal') e Exposição de Informações Sensíveis a um Ator Não Autorizado no componente Apache Camel Docling. Este problema afeta o Apache Camel: de 4.15.0 antes de 4.18.5, de 4.19.0 antes de 4.22.1. O DoclingProducer decidia o que significava um corpo de mensagem do tipo String inspecionando o seu prefixo. Um corpo começado por http:// ou https:// era entregue ao Docling como um URL remoto a obter, um corpo começado por / ou contendo uma barra invertida era lido do sistema de ficheiros local, e qualquer outra coisa era escrita num ficheiro temporário e convertida como conteúdo de documento. O modo era escolhido implicitamente e nenhuma opção de endpoint permitia ao autor de uma rota fixar o componente a uma única interpretação, pelo que uma rota que significa converter qualquer texto que chegue no corpo tornava-se silenciosamente num obtentor de recursos remotos ou num leitor de ficheiros locais sempre que o texto começasse por um desses prefixos. A única proteção aplicada ao valor derivado era uma verificação de tamanho, e essa verificação estava envolvida num teste de existência, pelo que um caminho que não resolvesse para nada, ou para um pseudo-ficheiro que reportasse um tamanho de zero, passava sem ser verificado de todo. Cinco locais de chamada alcançavam os dois sinks: o modo CLI acrescentava o valor como argumento posicional final do subprocesso docling, e o modo docling-serve passava-o ou para HttpSource para o backend obter ou para Files.readAllBytes para que o conteúdo pudesse ser codificado em base64 e carregado. Como o corpo do exchange nunca é filtrado por um HeaderFilterStrategy, ao contrário do namespace de cabeçalhos do Camel, um remetente capaz de colocar texto numa mensagem que uma rota encaminhe para um endpoint docling podia alcançar ambos os sinks sem qualquer opt-in da implementação. Recomenda-se aos utilizadores que atualizem para a versão 4.23.0, que corrige o problema. Se os utilizadores estiverem no ramo de releases 4.22.x, sugere-se que atualizem para 4.22.1. Se os utilizadores estiverem no ramo de releases 4.18.x, sugere-se que atualizem para 4.18.5. O ramo de releases 4.14.x e anteriores atingiu o fim de vida antes de este problema ser resolvido e não receberá uma correção, pelo que as implementações nessas linhas devem migrar para uma release suportada. Para implementações que não possam atualizar imediatamente, não encaminhe corpos de mensagem que tenham origem fora da implementação para um endpoint docling, e passe o documento através de um corpo tipado como File, byte[] ou InputStream, ou através do cabeçalho CamelDoclingInputFilePath, para que o corpo nunca fique sujeito a interpretação de prefixo.
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.