CVE-2026-79986
Limitación inadecuada de una ruta a un directorio restringido ('Path Traversal') en el componente Apache Camel Azure Files.
Este problema afecta a Apache Camel: desde la 4.0.0 anterior a la 4.18.5, desde la 4.19.0 anterior a la 4.22.1.
Los consumidores remote-file de Camel sondean un directorio de un servidor remoto y construyen la ruta remota absoluta de cada archivo concatenando el directorio configurado con el nombre de archivo indicado en el listado del directorio del servidor.
Leer descripción completaMostrar menos
Esa concatenación (FtpUtils.absoluteFilePath y GenericFileConsumer) no aplicaba normalización léxica alguna ni comprobaba que el resultado permaneciera dentro del directorio sondeado, y la ruta resultante pasaba a ser el operando de cada operación remota posterior sobre el archivo: la recuperación (FtpOperations.retrieveFile / SftpOperations, alcanzada desde GenericFileConsumer, donde el nombre de recuperación se toma literalmente de GenericFile.getAbsoluteFilePath), el borrado cuando delete=true (GenericFileDeleteProcessStrategy) y el renombrado cuando se configuran move, preMove, moveFailed o readLock=rename (GenericFileProcessStrategySupport y GenericFileRenameExclusiveReadLockStrategy). Ni isValidFile ni isMatched realizaban comprobación de contención alguna. Por tanto, una entrada del listado que no fuera un único segmento de ruta se resolvía a una ruta fuera del directorio de sondeo configurado, lo que hacía que Camel leyera, borrara o renombrara archivos fuera de él usando las propias credenciales del endpoint. El nombre del listado no son datos controlados por la ruta: lo suministra el servidor remoto, y el canal de control FTP no ofrece ninguna protección de integridad, de modo que un atacante en la ruta puede reescribir una respuesta LIST sin disponer de credenciales; un servidor comprometido, malicioso o multiinquilino, o un servidor respaldado por un sistema de archivos virtual, puede emitir directamente ese nombre. La recuperación es alcanzable en una configuración predeterminada del consumidor, ya que los consumidores remotos descargan todos los archivos listados; el borrado y el renombrado requieren además una de las opciones de disposición indicadas, todas ellas habituales. La salida del directorio que Camel estaba configurado para sondear es incondicional, mientras que la salida de los límites de la cuenta del propio servidor depende además de si dicho servidor confina la cuenta. La opción jailStartingDirectory, que se documenta como restricción de Camel al directorio de inicio y que está habilitada por defecto, regulaba las escrituras del productor y, desde el trabajo de contención de localWorkDirectory, las descargas del consumidor al directorio de trabajo local, pero no restringía este operando remoto, por lo que su nombre y su descripción afirmaban un límite que aquí no se aplicaba. El mismo punto de entrada ya se había reconocido en el lado local: la ruta de descarga de localWorkDirectory se restringió para que un nombre de archivo remoto que contuviera segmentos de directorio padre no pudiera resolverse fuera del directorio de trabajo local. El operando remoto era la mitad restante de esa superficie. Este artefacto proporciona el esquema azure-files. Su consumidor deriva de la misma clase base RemoteFileConsumer y componía la ruta remota mediante una función de concatenación simple, por lo que heredaba la misma resolución sin restricciones. Para alcanzarlo se requiere un nombre de listado que no sea un único segmento de ruta, cosa que el servicio REST de Azure Files no devuelve normalmente; la exposición se corrigió con el mismo criterio que los demás consumidores de remote-file, y no a partir de una prueba de concepto demostrada contra este esquema.
Actualice a Apache Camel 4.23.0, que corrige el problema. Los usuarios de la serie 4.22.x deben actualizar a la 4.22.1. Los usuarios de la serie LTS 4.18.x deben actualizar a la 4.18.5. La serie 4.14.x ha llegado al fin de su vida útil y no recibe esta corrección; sus usuarios deben migrar a una serie soportada.
Traducción automática del texto original de NVD (en inglés).
CVSS
- Puntuación base
- 7.4
- Versión
- 3.1
- Vector
- CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días
- 0.52 %
- Percentil entre todas las CVEs puntuadas
- 43
- Fecha de la puntuación
- 20/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Exploits públicos
Hay código de explotación o plantillas de detección públicos. No es lo mismo que explotación activa confirmada (KEV), pero aumenta el riesgo: parchee con prioridad.
- Prueba de concepto en GitHub (no verificada) · Lista de pruebas de concepto en GitHub
⚠️ Las pruebas de concepto de GitHub no están verificadas: algunas son falsas o contienen malware. No las ejecute nunca fuera de un laboratorio aislado.
Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1190Exploit Public-Facing Applicationinitial access75 % - Impacto principal
T1005Data from Local Systemcollection70 % - Impacto secundario
T1565Data Manipulationimpact50 %
Vector AV:N/PR:N/UI:N; el nombre de la listado remoto sin contención permite leer (y con delete/rename, borrar o mover) ficheros fuera del directorio de sondeo.
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
CWE
- CWE-22
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-79986",
"cveTags": [],
"metrics": {
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-79986",
"role": "CISA Coordinator",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"version": "2.0.3",
"timestamp": "2026-10-19T00:00:00+00:00"
}
}
],
"cvssMetricV31": [
{
"type": "Secondary",
"source": "security@apache.org",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 7.4,
"attackVector": "NETWORK",
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "HIGH",
"availabilityImpact": "NONE",
"privilegesRequired": "NONE",
"confidentialityImpact": "HIGH"
},
"impactScore": 5.2,
"exploitabilityScore": 2.2
}
]
},
"affected": [
{
"source": "security@apache.org",
"affectedData": [
{
"vendor": "Apache Software Foundation",
"product": "Apache Camel",
"versions": [
{
"status": "affected",
"version": "4.0.0",
"lessThan": "4.18.5",
"versionType": "maven"
},
{
"status": "affected",
"version": "4.19.0",
"lessThan": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.18.5",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.22.1",
"versionType": "maven"
},
{
"status": "unaffected",
"version": "4.23.0",
"versionType": "maven"
}
],
"packageURL": "pkg:maven/org.apache.camel/camel-azure-files",
"packageName": "org.apache.camel:camel-azure-files",
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected"
}
]
}
],
"published": "2026-10-19T11:17:20.860",
"references": [
{
"url": "https://camel.apache.org/security/CVE-2026-79986.html",
"source": "security@apache.org"
},
{
"url": "https://github.com/apache/camel/pull/25730",
"source": "security@apache.org"
},
{
"url": "https://github.com/apache/camel/pull/25745",
"source": "security@apache.org"
},
{
"url": "https://github.com/apache/camel/pull/25746",
"source": "security@apache.org"
},
{
"url": "https://github.com/apache/camel/pull/25747",
"source": "security@apache.org"
},
{
"url": "https://issues.apache.org/jira/browse/CAMEL-24487",
"source": "security@apache.org"
}
],
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"type": "Secondary",
"source": "security@apache.org",
"description": [
{
"lang": "en",
"value": "CWE-22"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Azure Files component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.\n\n\n\nThe Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint's own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel carries no integrity protection at all, so an on-path attacker can rewrite a LIST response without holding any credentials; a compromised, malicious or multi-tenant server, or a server backed by a virtual filesystem, can emit such a name directly. Retrieval is reachable in a default consumer configuration, since the remote consumers download every listed file; deletion and renaming additionally require one of the disposition options above, all of which are common. Escape from the directory Camel was configured to poll is unconditional, while escape from the server's own account boundary additionally depends on whether that server confines the account. The jailStartingDirectory option, which is documented as restricting Camel to the starting directory and is enabled by default, governed producer writes and, since the localWorkDirectory containment work, consumer downloads to the local work directory - but it did not constrain this remote operand, so its name and description claimed a boundary that was not enforced here. The same entry point had already been recognised on the local side: the localWorkDirectory download path was constrained so that a remote file name containing parent-directory segments could not resolve outside the local work directory. The remote operand was the remaining half of that surface. This artifact provides the azure-files scheme. Its consumer derives from the same RemoteFileConsumer base class and composed the remote path through a plain concatenation helper, so it inherited the same unconstrained resolution. Reaching it requires a listing name that is not a single path segment, which the Azure Files REST service does not normally return; the exposure was corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept against this scheme.\n\n\n\nUpgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does not receive this fix; users on it should move to a supported releases stream."
}
],
"lastModified": "2026-10-20T04:17:05.727",
"sourceIdentifier": "security@apache.org"
}