CVE-2026-66907 in Camel
Resumen
por VulDB • 2026-08-24
Vulnerabilidad de traversing de ruta relativa en el componente Google Storage de Apache Camel.
Este problema afecta a Apache Camel: desde la versión 4.0.0 hasta antes de la 4.14.9, desde la 4.15.0 hasta antes de la 4.18.4 y desde la 4.19.0 hasta antes de la 4.22.0.
El consumidor camel-google-storage descarga objetos de Google Cloud Storage en el sistema de archivos local cuando se establece la opción downloadFileName. Esta opción está documentada como una carpeta o un nombre de archivo, y cuando su valor no contiene ningún token de expresión, el consumidor construye el destino local añadiendo el nombre del objeto a dicha ruta: evaluateFileExpression configura la cabecera file-name del Exchange con el nombre del objeto remoto y evalúa downloadFileName + "/${file:name}". El token ${file:name} devuelve la cabecera file-name tal cual, a diferencia de ${file:onlyname}, que le aplica FileUtil.stripPath. La cadena resultante se pasó directamente a new File(result) y blob.downloadTo(file.toPath()) sin normalización léxica ni verificación de que el destino permaneciera dentro del directorio configurado. El nombre del objeto no es datos controlados por la ruta: el consumidor enumera el bucket, itera cada blob devuelto y crea un exchange por objeto a partir de blob.getBlobId().getName() tal cual, y la opción filter para restringir esos nombres no se aplica en absoluto a menos que se haya configurado explícitamente. Los nombres de los objetos de Google Cloud Storage son claves UTF-8 opacas que el servicio almacena y enumera exactamente como fueron escritas, sin canonización del lado del servidor, y una barra diagonal solo es una convención visual para pseudo-directorios; por lo tanto, un nombre clave que contenga segmentos de directorio padre sobrevive al ciclo completo intacto. Un nombre de objeto con dichos segmentos se resolvía en una ubicación fuera del directorio downloadFileName configurado, permitiendo a cualquier persona capaz de influir en los nombres presentes en el bucket consumido hacer que Camel cree o sobrescriba un archivo en la ubicación elegida por ella misma, con los privilegios del proceso de Camel. Dependiendo de lo que 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 downloadFileName es un parámetro de consumidor ordinario y no tiene ningún marcador de seguridad, por lo que nada señalaba a los usuarios que su valor no se estaba aplicando como una frontera de contención. El defecto es solo del consumidor; el productor no tiene un sumidero de descarga a archivo. Los otros consumidores de descarga de archivos de Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files y las rutas de descarga de Azure Storage - ya limitaban sus descargas locales al directorio configurado mediante una verificación del límite de segmentos de ruta; camel-google-storage era el único sumidero de descarga de almacén de objetos no cubierto por ese trabajo.
Se recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Si los usuarios están en la rama LTS de versiones 4.14.x, se les sugiere actualizar a la 4.14.9. Si los usuarios están en la rama de lanzamientos 4.18.x, se les sugiere actualizar a la 4.18.4. Para implementaciones que no puedan actualizarse inmediatamente, configuren la opción filter con una expresión regular que acepte solo nombres de objetos simples de un solo segmento, para que cualquier nombre que lleve un separador de ruta o un segmento de directorio padre sea excluido antes de crear un exchange; tenga en cuenta que no se aplica ningún filtrado cuando la opción no está configurada y que la expresión coincide con todo el nombre del objeto. Alternativamente, asigne a downloadFileName una expresión explícita que no transmita la ruta remota, por ejemplo, una basada en ${file:onlyname} en lugar de la implícita ${file:name}, teniendo en cuenta que un downloadFileName que contiene una expresión se trata como controlado por la ruta y no está cubierto por la verificación de contención añadida en la corrección. Como defensa en profundidad, trate los nombres de objetos en cualquier bucket escribible externamente como entrada no confiable y no derive rutas del sistema de archivos local a partir de ellos.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.