CVE-2026-60093
Apache Camel: Camel-Azure-Storage-DataLake: la operación downloadToFile construía el destino de descarga local a partir del nombre de la ruta remota sin restringirlo al fileDir configurado
- Publicado
- 24 ago 2026
- Actualizado
- 25 ago 2026
- Asignación de CNA
- apache
- Evidencia observada
- 24 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NBajo · próximos 30 días
- Percentil
- 17,7 %
- Fecha del modelo
- 21 sept 2026
EPSS es una estimación estadística, no una certeza o una medida de impacto. Combínelo con CVSS, estado KEV, exposición y su entorno.
Resumen
Vulnerabilidad de salto de directorio relativo (path traversal) en el componente Azure-Storage Datalake de Apache Camel. Este problema afecta a Apache Camel: desde 4.0.0 hasta antes de 4.14.9, desde 4.15.0 hasta antes de 4.18.4, desde 4.19.0 hasta antes de 4.22.0. El componente camel-azure-storage-datalake puede descargar un archivo de Azure Data Lake Storage Gen2 al sistema de archivos local a través de su operación downloadToFile, escribiendo en el directorio indicado por la opción de endpoint fileDir. DataLakeFileOperations.downloadToFile construía el destino local uniendo fileDir con el nombre de la ruta remota exactamente tal como lo informaba el SDK de Azure (new File(fileDir, fileClientWrapper.getFileName())) y pasaba el resultado directamente a la llamada de descarga del SDK, sin normalización léxica ni comprobación de que la ubicación resuelta permaneciera dentro de fileDir. El nombre remoto no es un dato controlado por la ruta: el consumidor enumera el sistema de archivos en DataLakeConsumer.createBatchExchangesFromPath, que lista las rutas y crea un exchange por cada entrada a partir de PathItem.getName() tal cual, sin aplicar ningún filtro de nombres por defecto. Un nombre de ruta que contenga segmentos de directorio padre se resolvía, por tanto, a una ubicación fuera del fileDir configurado, lo que permitía que cualquier persona capaz de influir en los nombres presentes en el sistema de archivos Data Lake consumido hiciera que Camel creara o sobrescribiera un archivo en una ubicación de su elección, con los privilegios del proceso de Camel. Dependiendo de a qué pueda escribir el proceso, sobrescribir un archivo fuera del directorio de descarga puede escalar más allá de la pérdida de integridad de ese archivo. La opción fileDir es un parámetro de configuración ordinario del grupo común y no lleva ningún marcador de seguridad, por lo que nada indicaba a los usuarios que su valor no se estaba aplicando como límite de contención. Los demás consumidores de descarga de archivos de Camel —camel-file, camel-ftp, camel-smb, camel-mina-sftp y camel-azure-files— ya restringían sus descargas locales al directorio configurado mediante una comprobación de límite por segmentos de ruta; la vía de descarga de camel-azure-storage-datalake no estaba cubierta por ese trabajo. Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Si los usuarios se encuentran en la rama de versiones LTS 4.14.x, se les sugiere actualizar a 4.14.9. Si los usuarios se encuentran en la rama de versiones 4.18.x, se les sugiere actualizar a 4.18.4. Para los despliegues que no puedan actualizar de inmediato, restrinja los nombres sobre los que actuará el consumidor mediante la opción de endpoint regex, que se aplica a cada nombre de ruta listado como una coincidencia de cadena completa, de modo que solo se acepten nombres simples de un solo segmento y cualquier nombre que contenga un separador de ruta o un segmento de directorio padre se filtre antes de que se cree un exchange. Alternativamente, evite la operación downloadToFile en sistemas de archivos no confiables y escriba la carga útil desde la ruta bajo un nombre de archivo que la propia ruta controle, en lugar de uno tomado del listado remoto. Como defensa en profundidad, trate los nombres de objeto en cualquier sistema de archivos Data Lake escribible externamente como entrada no confiable y no derive rutas del sistema de archivos local a partir de ellos.
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.