CVE-2026-78163
Apache Camel: la fuente de entrada del cuerpo de mensaje no validado de Camel-Docling permite Server-Side Request Forgery y divulgación de archivos locales
- Publicado
- 19 oct 2026
- Actualizado
- 19 oct 2026
- Asignación de CNA
- apache
- Evidencia observada
- 17 oct 2026
CVSS primario
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NResumen
Vulnerabilidad de Server-Side Request Forgery (SSRF), Limitación Incorrecta de un Nombre de Ruta a un Directorio Restringido ('Path Traversal') y Exposición de Información Sensible a un Actor No Autorizado en el componente Apache Camel Docling. Este problema afecta a Apache Camel: desde 4.15.0 antes de 4.18.5, desde 4.19.0 antes de 4.22.1. DoclingProducer decidía qué significaba un cuerpo de mensaje de tipo String inspeccionando su prefijo. Un cuerpo que comenzara con http:// o https:// se entregaba a Docling como una URL remota para obtener, un cuerpo que comenzara con / o que contuviera una barra invertida se leía del sistema de archivos local, y cualquier otra cosa se escribía en un archivo temporal y se convertía como contenido de documento. El modo se elegía de forma implícita y ninguna opción de endpoint permitía a un autor de ruta fijar el componente a una única interpretación, por lo que una ruta que pretendía convertir cualquier texto que llegara en el cuerpo se convertía silenciosamente en un obtenedor de recursos remotos o en un lector de archivos locales siempre que el texto comenzara con uno de esos prefijos. La única protección aplicada al valor derivado era una comprobación de tamaño, y esa comprobación estaba envuelta en una prueba de existencia, por lo que una ruta que no resolvía a nada, o a un pseudoarchivo que reportaba un tamaño de cero, pasaba sin ser comprobada en absoluto. Cinco puntos de llamada alcanzaban los dos sinks: el modo CLI añadía el valor como argumento posicional final del subproceso docling, y el modo docling-serve lo pasaba a HttpSource para que el backend lo obtuviera o a Files.readAllBytes para que el contenido pudiera codificarse en base64 y subirse. Debido a que el cuerpo del exchange nunca es filtrado por un HeaderFilterStrategy, a diferencia del espacio de nombres de cabeceras de Camel, un remitente capaz de colocar texto en un mensaje que una ruta reenvía a un endpoint docling podía alcanzar ambos sinks sin ningún opt-in por parte del despliegue. Se recomienda a los usuarios actualizar a la versión 4.23.0, que corrige el problema. Si los usuarios están en la rama de versiones 4.22.x, se sugiere que actualicen a 4.22.1. Si los usuarios están en la rama de versiones 4.18.x, se sugiere que actualicen a 4.18.5. La rama de versiones 4.14.x y anteriores alcanzaron el fin de su ciclo de vida antes de que se resolviera este problema y no recibirán una corrección, por lo que los despliegues en esas líneas deben migrar a una versión compatible. Para los despliegues que no puedan actualizar de inmediato, no enruten cuerpos de mensaje que se originen fuera del despliegue hacia un endpoint docling, y pasen el documento a través de un cuerpo tipado como File, byte[] o InputStream, o a través de la cabecera CamelDoclingInputFilePath, de modo que el cuerpo nunca esté sujeto a la interpretación de prefijos.
Fuentes
Reproductor de prueba de concepto ejecutable para CVE-2026-78163 en Apache Camel camel-docling, que demuestra SSRF y divulgación de archivos locales mediante una entrada de cuerpo String no validada, con un control de compilación corregida.
Uso responsable
Utilice información sobre vulnerabilidades solo en sistemas de su propiedad o que esté autorizado a probar. Kitploit enlaza con metadatos de investigación pública y no almacena código de explotación ni cargas útiles maliciosas.