Glosario

Qué es el path traversal (recorrido de rutas): leer archivos que el servidor nunca debería servir, mediante ../

El path traversal usa ../ para leer o escribir archivos fuera de la carpeta prevista, como .env o claves. Cómo funciona y cómo evitarlo confinando las rutas.

Publicado 2026-06-10 Actualizado 2026-10-06 8 min de lectura
En esta página

El path traversal es cuando poner ../ en un campo de nombre de archivo hace legible un archivo .env situado en lo profundo del servidor. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).

Dónde aparece

En cualquier sitio donde «la entrada del usuario elige un archivo».

FunciónEl uso peligroso
Descarga / vista previaUsar ?file= directamente como nombre de archivo
Mostrar imágenes / adjuntosConstruir parte de la ruta a partir de un parámetro de URL
SubidaUsar un nombre proporcionado por el usuario en la ruta de guardado (tipo escritura, el más peligroso)
Carga de plantillas / idiomasElegir un archivo dinámicamente mediante ?lang=, etc.

Por qué funciona

../ significa «subir un nivel». Si la aplicación concatena carpeta pública + entrada del usuario y abre ese archivo, los segmentos ../ apilados dejan que la solicitud alcance archivos fuera de la carpeta pública.

Previsto: /var/www/files/ + entrada del usuario
La entrada apila «subir un nivel» (../ ../ ../ …)
↓ la aplicación concatena sin normalizar y luego open()
Alcanza fuera de la base (.env, configuración, claves, /etc) = lectura/escritura
Concatena la entrada del usuario a la carpeta base y los ../ apilados alcanzan archivos fuera de ella.

Leer significa divulgación; escribir (subidas) significa archivos plantados en cualquier sitio, lo que puede llevar a RCE.

Defensa: no uses la entrada como ruta + confina a la base

1

Nunca uses la entrada del usuario como ruta de archivo en bruto (lo más importante)

Resuelve los archivos expuestos mediante una lista de permitidos ID → archivo real. El usuario pasa solo un identificador («3», «factura»); el servidor decide la ruta real.

2

Normaliza y luego verifica que queda dentro del directorio base

Conviértela en una ruta absoluta con el resolutor del lenguaje (resolve/realpath) y comprueba que empieza por el directorio base permitido. Rechaza todo lo que quede fuera. La eliminación ingenua de la cadena '../' falla ante las elusiones por codificación.

3

Ejecuta la aplicación con privilegios mínimos

Limita qué archivos puede leer el usuario de ejecución de la aplicación a lo que la tarea necesite. Aunque alguien escape, los archivos ilegibles no filtran nada.

4

Mantén los secretos completamente fuera de la raíz pública

No coloques .env, .git, claves ni copias de seguridad en la raíz web o en la carpeta de subidas para empezar. Solo con la ubicación ya eliminas lo que podría atacarse.

La visión de este sitio: es el mismo tipo de problema que los errores de ubicación, así que corrige en el orden correcto

El path traversal es el mismo tipo de problema que el incidente de exposición de .env: ambos son «algo que nunca debería ser alcanzable por la web se vuelve alcanzable por la web». Las medidas temporales (cabeceras, filtros ingenuos) solo cubren la superficie; si el código y la ubicación no se corrigen, otra vía sigue filtrando. El orden es (1) código que no usa la entrada como ruta, (2) confinamiento al directorio base, (3) mantener los secretos fuera de la raíz pública. Lee ubicación segura en hosting compartido junto a esto para ver cómo funciona la solución de raíz.

En qué se diferencia de problemas parecidos

El resultado puede parecer el mismo, «un archivo que debería ser privado se puede leer desde fuera», pero la causa decide dónde se corrige.

ProblemaCausaDónde se corrige
Path traversalUna entrada que apunta a un archivo puede escapar de la ubicación permitidaCódigo de la aplicación (no usar la entrada como ruta)
Inclusión de archivos locales (LFI)La entrada elige un archivo que el programa carga y ejecutaCódigo de la aplicación (fijar qué archivos se pueden cargar)
Archivos olvidados en un directorio público.env o .git están donde la web puede verlos (→ secretos olvidados en directorios públicos)Ubicación de archivos y configuración del servidor web
IDOREl ID del archivo tiene un formato válido pero puede apuntar al archivo de otra personaComprobaciones de permisos de la aplicación

Casos reales: fallos en el propio servidor web

El path traversal no solo aparece en aplicaciones propias, sino también en productos muy utilizados.

  • Apache HTTP Server 2.4.49 (2021): tenía un fallo de path traversal (CVE-2021-41773), y el proyecto Apache indicó que se sabía que se estaba explotando. La versión 2.4.50 lo corrigió, pero la corrección estaba incompleta (CVE-2021-42013), así que se volvió a corregir en la 2.4.51. Según la configuración, no solo permitía leer archivos, sino también llegar a una RCE.
  • Núcleo de WordPress (2026): un path traversal en el código que resuelve las plantillas de página dio lugar a un fallo de inclusión de archivos (CVE-2026-87902) que puede llegar a una RCE en ciertas condiciones (→ CVE-2026-87902 explicada, en inglés).

En mayo de 2024, las agencias estadounidenses CISA y FBI emitieron una alerta pidiendo a los fabricantes eliminar este tipo de fallo. Según indicaron, en ese momento el KEV de CISA (la lista de vulnerabilidades con explotación confirmada) contenía 55 vulnerabilidades de directory traversal. En la lista «CWE Top 25» de MITRE publicada en diciembre de 2025, el path traversal (CWE-22) ocupa el sexto puesto.

Cómo revisar tu propio sitio

1

Localiza las operaciones con archivos que reciben entrada

Busca en tu código funciones que abren o envían archivos (open, readFile, sendFile, include, etc.) o que construyen rutas (path.join y similares) a las que puedan llegar valores de la petición.

2

Revisa el orden de las comprobaciones

Donde se use la entrada, confirma que primero se normaliza la ruta (path.resolve o realpath) y solo después se comprueba que queda dentro del directorio base. Si el código solo inspecciona la cadena antes de normalizar, corrige el orden.

3

Revisa las versiones de tu servidor web y tus productos

Asegúrate de no usar versiones con path traversal conocido, como Apache 2.4.49 o 2.4.50. La consulta de CVE / KEV muestra las vulnerabilidades conocidas de los productos que usas.

4

Comprueba que no se ven archivos que deben estar ocultos

Usa la auditoría del sitio para comprobar que .env, .git y los volcados de base de datos no se pueden leer desde fuera. Si se pueden, corrige la ubicación como una tarea separada del path traversal.

Fuentes (primarias)

  • CISA y FBI, «Secure by Design Alert: Eliminating Directory Traversal Vulnerabilities in Software» (2 de mayo de 2024) — cisa.gov (en inglés; 55 entradas en el KEV, uso de identificadores aleatorios)
  • Apache HTTP Server, «Apache HTTP Server 2.4 vulnerabilities» — httpd.apache.org (en inglés; CVE-2021-41773, CVE-2021-42013)
  • MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (diciembre de 2025) — cwe.mitre.org (en inglés; CWE-22 en sexto puesto)
  • OWASP, «Path Traversal» — owasp.org (en inglés)
  • IPA, «How to Secure Your Web Site» — ipa.go.jp (en japonés; parámetros de ruta sin comprobar / directory traversal)

Sigue leyendo

Clasificación

CWE clasifica los tipos de debilidad que causan las vulnerabilidades; MITRE ATT&CK clasifica las técnicas de los atacantes. Ambos los mantiene MITRE y se usan ampliamente para etiquetar vulnerabilidades y reglas de detección.

CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use

FAQ

Q¿Qué se filtra en un path traversal?
A

Archivos que la aplicación nunca debía exponer: .env (credenciales de la base de datos, claves de API), archivos de configuración, claves privadas, código fuente, rutas del sistema operativo como /etc. Más allá de leer, si alcanza la ruta de destino de una subida, puede escribir en cualquier sitio y escalar a RCE (ejecución remota de código).

Q¿Cuál es la mejor defensa?
A

Nunca uses la entrada del usuario como ruta de archivo en bruto. Si debes hacerlo, mapéala a través de una lista de permitidos (un conjunto fijo de IDs/nombres de archivo), normaliza la ruta con una librería y verifica que el resultado queda dentro del directorio base permitido. Las comprobaciones de extensión o la eliminación ingenua de '../' se eluden.

Q¿Puedo bloquearlo simplemente con .htaccess o cabeceras?
A

Eso es una medida temporal para un problema distinto (archivos sensibles ubicados en la raíz web). La solución de raíz es colocar el cuerpo de la aplicación, .env y .git FUERA de la raíz pública, además de código que no use la entrada como ruta. La medida temporal y la solución de raíz son tareas separadas.

Q¿Directory traversal y path traversal son lo mismo?
A

Sí. La guía de la IPA de Japón lo llama directory traversal y la clasificación de MITRE (CWE-22) lo llama Path Traversal. Ambos significan que una entrada que apunta a un archivo alcanza archivos fuera de la ubicación permitida.

Q¿Asignar IDs aleatorios a los archivos lo evita?
A

Es un enfoque eficaz. En su alerta de mayo de 2024, las agencias estadounidenses CISA y FBI recomiendan generar un identificador aleatorio para cada archivo y guardar por separado la información relacionada, como el nombre original. Así la entrada del usuario nunca forma parte de una ruta y este tipo de fallo no tiene dónde producirse.

Q¿En qué se diferencia de la inclusión de archivos locales (LFI)?
A

El path traversal significa que se pueden leer o escribir archivos fuera de la ubicación permitida. La LFI significa que la entrada elige un archivo que el programa carga y ejecuta, y a menudo se usa el path traversal para apuntar a un archivo de fuera. Como la LFI ejecuta el archivo como código en lugar de solo leerlo, lleva más fácilmente a una RCE.