Empresa
¿Quiénes somos? Visión y Valores
Herramientas
Email Checker Vigía DNS SSL Checker Password Strength HTTP Headers Password Generator VPN PSK Generator
Alertas
Todas las alertas Vulnerabilidades Incidentes Solo críticas En CISA KEV Vigía LATAM
Editorial
Análisis técnico ¿Cuál es mi IP?
Blog
Blog 2MCI Noticias ISO 27001 Amenazas LATAM Recursos Gratuitos eBook Gratuito Newsletter Podcast / YouTube
Empresa
Servicios Contacto Suscribirse al Newsletter
Nuevo en 2MCI
Crear cuenta gratis Ver herramientas sin registro
Ya tengo cuenta
Iniciar sesión
Equipo
Portal interno 2MCI
Alto CVE-2026-79985 Multiple Vendors

Vulnerabilidad de traversal de directorios en Apache Camel SMB (CVE-2026-79985)

Vulnerabilidad · Publicado 19/10/2026

7.4
CVSS 3.x
04 Medio7 Alto9 Crítico10
Severidad: Alto
Resumen ejecutivo

Apache Camel versiones 4.2.0 a 4.18.4 y 4.19.0 a 4.22.0 contienen una vulnerabilidad de path traversal en el componente SMB que permite acceso no autorizado a directorios del servidor remoto. Un atacante podría manipular nombres de archivo para acceder a rutas restringidas durante la replicación de archivos. Afecta directamente a empresas en LATAM que utilizan Camel para integración de sistemas y procesamiento de archivos en infraestructuras de red compartida.

Análisis asistido por IA, contexto LATAM revisado por el equipo 2MCI.

Descripción técnica

Descripción técnica

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel SMB component. This issue affects Apache Camel: from 4.2.0 before 4.18.5, from 4.19.0 before 4.22.1. The 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 smb scheme. Its consumer walks the share listing on its own rather than through RemoteFileConsumer, skipping only the exact "." and ".." entries, so a name carrying traversal segments in any other form was concatenated unchecked. Reaching it requires a server that emits a listing name which is not a single path segment, which a conforming SMB2 implementation does not do; 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. Upgrade 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.

Puntuación CVSS

Score: 7.4/10 — Severidad: HIGH — Estado NIST: Received

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Debilidades (CWE)

CWE-22

Fuente oficial

Publicado en NIST NVD.

¿Qué hacer?
  • Actualizar Apache Camel a versión 4.18.5 o posterior (línea 4.18.x) y 4.22.1 o posterior (línea 4.19+)
  • Revisar logs de acceso SMB para detectar intentos de traversal en directorios
  • Implementar validación de rutas en aplicaciones que usen componentes remote-file
  • Aplicar controles de permisos restrictivos en servidores SMB
  • Priorizar según exposición de sistemas críticos que procesen datos sensibles
Esta alerta fue generada automáticamente a partir del NVD del NIST.