CVE-2026-66906

{"id": "CVE-2026-66906", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-66906", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-25T19:36:45.646535Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 3.9}]}, "affected": [{"source": "security@apache.org", "affectedData": [{"vendor": "Apache Software Foundation", "product": "Apache Camel", "versions": [{"status": "affected", "version": "4.0.0", "lessThan": "4.14.9", "versionType": "semver"}, {"status": "affected", "version": "4.15.0", "lessThan": "4.18.4", "versionType": "semver"}, {"status": "affected", "version": "4.19.0", "lessThan": "4.22.0", "versionType": "semver"}], "packageURL": "pkg:maven/org.apache.camel/camel-azure-storage-blob", "packageName": "org.apache.camel:camel-azure-storage-blob", "collectionURL": "https://repo.maven.apache.org/maven2", "defaultStatus": "unaffected"}]}], "published": "2026-08-24T17:18:06.147", "references": [{"url": "https://camel.apache.org/security/CVE-2026-66906.html", "tags": ["Mailing List", "Vendor Advisory"], "source": "security@apache.org"}, {"url": "http://www.openwall.com/lists/oss-security/2026/08/24/10", "tags": ["Mailing List", "Third Party Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Secondary", "source": "security@apache.org", "description": [{"lang": "en", "value": "CWE-23"}]}], "descriptions": [{"lang": "en", "value": "Relative path traversal vulnerability in Apache Camel Azure Storage Blob component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.\n\n\n\nThe camel-azure-storage-blob component can download an Azure Storage blob to the local filesystem through its downloadBlobToFile operation, writing into the directory named by the fileDir endpoint option, which is documented as usable from both the producer and the consumer. BlobOperations.downloadBlobToFile built the local target by joining fileDir with the remote blob name exactly as the Azure SDK reported it (new File(fileDir, client.getBlobName())) and passed the result straight to the SDK download call, with no lexical normalization and no check that the resolved location stayed inside fileDir. The blob name is not route-controlled data: the consumer enumerates the container in BlobConsumer.createBatchExchangesFromContainer, which lists blobs and creates one exchange per entry from BlobItem.getName() verbatim, applying no name filtering by default. A blob name containing parent-directory segments therefore resolved to a location outside the configured fileDir, letting anyone able to influence the names present in the consumed container cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. Azure Storage blob containers use a flat namespace in which the blob name is an opaque key, so a name carrying such segments is stored and listed as given. The fileDir option is an ordinary common-group configuration parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp and camel-azure-files - already constrained their local downloads to the configured directory using a path-segment boundary check; the camel-azure-storage-blob download path was not covered by that work.\n\n\n\nUsers are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, constrain the names the consumer will act on using the regex endpoint option, which is applied to each listed blob name as a full-string match, so that only simple single-segment names are accepted and any name carrying a path separator or a parent-directory segment is filtered out before an exchange is created; the prefix option can additionally narrow the listing server-side, noting that when both are set regex takes priority and prefix is ignored. Alternatively, avoid the downloadBlobToFile operation on untrusted containers and write the payload from the route under a file name the route itself controls, rather than one taken from the remote listing. As defence in depth, treat the blob names in any externally writable container as untrusted input and do not derive local filesystem paths from them."}, {"lang": "es", "value": "Vulnerabilidad de salto de ruta relativo en el componente Apache Camel Azure Storage Blob.\n\nEste problema afecta a Apache Camel: desde 4.0.0 antes de 4.14.9, desde 4.15.0 antes de 4.18.4, desde 4.19.0 antes de 4.22.0.\n\nEl componente camel-azure-storage-blob puede descargar un blob de Azure Storage al sistema de archivos local a trav\u00e9s de su operaci\u00f3n downloadBlobToFile, escribiendo en el directorio nombrado por la opci\u00f3n de endpoint fileDir, que est\u00e1 documentada como utilizable tanto por el productor como por el consumidor. BlobOperations.downloadBlobToFile construy\u00f3 el destino local uniendo fileDir con el nombre del blob remoto exactamente como lo inform\u00f3 el SDK de Azure (new File(fileDir, client.getBlobName())) y pas\u00f3 el resultado directamente a la llamada de descarga del SDK, sin normalizaci\u00f3n l\u00e9xica y sin verificar que la ubicaci\u00f3n resuelta permaneciera dentro de fileDir. El nombre del blob no es un dato controlado por la ruta: el consumidor enumera el contenedor en BlobConsumer.createBatchExchangesFromContainer, que lista blobs y crea un intercambio por entrada de BlobItem.getName() textualmente, sin aplicar filtrado de nombres por defecto. Un nombre de blob que contiene segmentos de directorio padre, por lo tanto, se resolvi\u00f3 a una ubicaci\u00f3n fuera del fileDir configurado, permitiendo que cualquiera capaz de influir en los nombres presentes en el contenedor consumido haga que Camel cree o sobrescriba un archivo en una ubicaci\u00f3n de su elecci\u00f3n, con los privilegios del proceso de Camel. Dependiendo de d\u00f3nde pueda escribir el proceso, sobrescribir un archivo fuera del directorio de descarga puede escalar m\u00e1s all\u00e1 de la p\u00e9rdida de integridad de ese archivo. Los contenedores de blobs de Azure Storage utilizan un espacio de nombres plano en el que el nombre del blob es una clave opaca, por lo que un nombre que contenga dichos segmentos se almacena y se lista tal cual. La opci\u00f3n fileDir es un par\u00e1metro de configuraci\u00f3n ordinario de grupo com\u00fan y no lleva ning\u00fan marcador de seguridad, por lo que nada indicaba a los usuarios que su valor no se estaba aplicando como un l\u00edmite de contenci\u00f3n. Otros consumidores de descarga de archivos de Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp y camel-azure-files - ya restring\u00edan sus descargas locales al directorio configurado utilizando una verificaci\u00f3n de l\u00edmite de segmento de ruta; la ruta de descarga de camel-azure-storage-blob no estaba cubierta por ese trabajo.\n\nSe recomienda a los usuarios actualizar a la versi\u00f3n 4.22.0, que corrige el problema. Si los usuarios est\u00e1n en la rama de versiones LTS 4.14.x, se les sugiere actualizar a 4.14.9. Si los usuarios est\u00e1n en la rama de versiones 4.18.x, se les sugiere actualizar a 4.18.4. Para implementaciones que no pueden actualizarse inmediatamente, restrinja los nombres sobre los que actuar\u00e1 el consumidor utilizando la opci\u00f3n de endpoint regex, que se aplica a cada nombre de blob 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 intercambio; la opci\u00f3n prefix puede adem\u00e1s reducir la lista en el lado del servidor, teniendo en cuenta que cuando ambos est\u00e1n configurados, regex tiene prioridad y prefix se ignora. Alternativamente, evite la operaci\u00f3n downloadBlobToFile en contenedores no confiables y escriba la carga \u00fatil de la ruta bajo un nombre de archivo que la propia ruta controle, en lugar de uno tomado de la lista remota. Como defensa en profundidad, trate los nombres de los blobs en cualquier contenedor escribible externamente como entrada no confiable y no derive rutas del sistema de archivos local a partir de ellos."}], "lastModified": "2026-10-12T15:10:00.207", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "DEBE8FE2-2989-4FC0-B805-C740A8FDF42A", "versionEndExcluding": "4.14.9", "versionStartIncluding": "4.0.0"}, {"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "7BC98A81-8301-4163-A47E-C6A9332A2454", "versionEndExcluding": "4.18.4", "versionStartIncluding": "4.15.0"}, {"criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "10DE8B35-C125-4461-A7F7-3BDA3E3CB316", "versionEndExcluding": "4.22.0", "versionStartIncluding": "4.19.0"}], "operator": "OR"}]}], "sourceIdentifier": "security@apache.org"}