1. Resumen del CVE

Nota honesta: La descripción del CNA solo indica path traversal → DoS sin detalles. Este writeup reconstruye la ubicación del bug mediante el diff r26.05..r26.06 y pruebas directas en el contenedor 26.05-py3.

2. Entorno de Laboratorio

Imagen: nvcr.io/nvidia/tritonserver:26.05-py3 (TRITON_VERSION 2.69.0)

Compose siempre en explicit (ya parcheado en este repo):

run_triton.bat:10, run_triton.ps1:11, run_triton.sh:12 también están en explicit.

Modo Triton:

• NONE (predeterminado upstream) → carga una vez al inicio, POST /v2/repository/models/.../load → 503, requiere reinicio para cargar un modelo nuevo.
• POLL → escanea el repo cada segundo, auto-carga, sigue bloqueando la carga explícita.
• EXPLICIT (este repo) → no escanea, pero abre gRPC load_model / POST /load → PoC sin reinicio vía gRPC.

Puertos: | 8000 | HTTP REST | v2/health, v2/models, v2/repository | | 8001 | gRPC | RepositoryModelLoad, ModelInfer | | 8002 | Métricas | Prometheus |

Modelo inicial:

Inicio rápido:

3. Anatomía de la Vulnerabilidad

• Si join sin canonicalize o la verificación rfind(parent,0)==0 es incorrecta (coincidencia parcial /models vs /models_evil), entonces ../ puede escapar.
• DoS ocurre si el archivo atravesado es un FIFO, /dev/zero, /proc/self/mem, o un tar que contiene ../../ que sobrescribe archivos del sistema → cuelgue / OOM / crash.

Tres preguntas de investigación (del informe inicial):

1. ¿Dónde controla el usuario la ruta? → model_name en gRPC RepositoryModelLoad, entrada tar EXECUTION_ENV_PATH, override file:, TRITON_BATCH_STRATEGY_PATH.
2. ¿Cómo se usa la ruta? → posixpath.join(repo, model_name) / temp_dir + "/" + file_name + IsChildPathEscapingParentPath.
3. ¿Cuál es el impacto? → DoS vía agotamiento de recursos / cuelgue. En este repo se demuestra escritura de archivos en /tmp/poc_marker.

4. Análisis de Causa Raíz (Diff 26.05 → 26.06)

Repo core (r26.05..r26.06):

1. src/filesystem/api.cc:407 IsChildPathEscapingParentPath — fix dcb315d + 72f3d9b:

   root@kitploit:~

   // VULNERABLE (r26.05):
   absolute_child.rfind(absolute_parent,0) != 0
   // → bug de coincidencia parcial: el prefijo "/models" de "/models_evil/file" se considera interno
   
   // CORREGIDO (r26.06):
   canonical_child.find(canonical_parent,0)==0 &&
   ((child.size() > parent.size() && child[parent.size()]=='/') || child.size()==parent.size())
   // → debe haber '/' después del prefijo, "/models_evil" ahora está correctamente fuera
   

   Usado en src/backend_model.cc:196 (TRITON_BATCH_STRATEGY_PATH) y src/model_repository_manager/model_repository_manager.cc:162 (file:).

2. src/model_repository_manager/model_repository_manager.cc:62 ValidateModelName — core#472/#481 (marzo 2026, ya en 26.05 pero reforzado en 26.06):

   root@kitploit:~

   if (trimmed==".." || trimmed.find('/')!=npos) return INVALID_ARG "must not contain path traversal"
   

   Esto es lo que hace que gRPC load_model('../tmp/pwn') → 400 INVALID_ARGUMENT en 26.05 (ya bloqueado). Pero %2f (/ codificado) pasa porque no es un / literal → 500 de poll literal.

3. python_be.cc:292 EXECUTION_ENV_PATH — e520f8c7 test zipslip_test.py: El tar se extrae sin verificar .. / rutas absolutas. La entrada ../../poc_marker de /models/poc_exploit/malicious_env.tar.gz se extrae a /tmp/poc_marker (fuera del directorio del modelo). Fix en 26.06: usar ARCHIVE_EXTRACT_SECURE_NODOTDOT|NOABSOLUTEPATHS + verificación IsChildPathEscapingParentPath.

Repo server (r26.05..r26.06): solo sagemaker_server.cc:1027 (verificación RE2::FullMatch) + http_server.cc:2440 (atoi→stoi), no es la ruta de este CVE.

Conclusión: La ruta model_name vía HTTP/gRPC ya está bloqueada en 26.05 por ValidateModelName, pero el Zip-Slip del tar no — esto es lo que explota el PoC de este repo.

5. Rutas de Explotación: ¿Cuáles Afectan Realmente?

La analogía 500 vs 400 en el writeup anterior era incorrecta: 500 = archivo no existe (la puerta no está), 400 = rechazado por validación (la puerta está cerrada con llave). Ninguno entra. Solo 200 + archivo en /tmp es evidencia.

6. PoC Principal: Zip-Slip vía EXECUTION_ENV_PATH

Idea: El parámetro del backend Python EXECUTION_ENV_PATH apunta a $$TRITON_MODEL_DIRECTORY/malicious_env.tar.gz. Cuando se ejecuta load_model('poc_exploit'), el backend pb_env.cc:292 extrae el tar sin sanitización. La entrada ../../poc_marker escapa de .../poc_exploit/ a /tmp/poc_marker.

Pasos del PoC (automatizado en scripts/exploit.py:28 y exploit.ps1:20):

1. Copiar echo_python → poc_exploit (scripts/exploit.py:35)
2. Añadir config.pbtxt (scripts/exploit.py:40):
   root@kitploit:~

   parameters: {key: "EXECUTION_ENV_PATH", value: {string_value: "$$TRITON_MODEL_DIRECTORY/malicious_env.tar.gz"}}
   

3. Crear el tar (scripts/exploit.py:44):
   root@kitploit:~

   TarInfo(name='../../poc_marker', size=6, mode=0o644)  # → /tmp/poc_marker
   TarInfo(name='bin/activate', mode=0o755)
   

4. Disparar gRPC load_model('poc_exploit') (scripts/exploit.py:60) — sin reinicio porque está en explicit.
5. Verificar docker exec tritonserver-test cat /tmp/poc_marker → pwned (scripts/exploit.py:81)

7. Cómo Ejecutar el PoC (One-Click)

Requisitos previos: Docker, imagen 26.05-py3 ya con docker compose up -d (el repo ya está en explicit).

Python (sin reinicio, vía gRPC):

PowerShell:

Volver a MODE_NONE (si se desea el upstream predeterminado):

Prueba de bloqueo (debe dar 400/404/500, no 200):

8. Evidencia de Traversal (No un 500 Falso)

Vulnerable (26.05) — salida de exploit.py:

Verificación:

Parcheado (26.06) — esperado:

HTTP/gRPC .. debe dar 400, no 500:

9. Impacto DoS

El CNA indica DoS, pero este Zip-Slip puede hacer sobrescritura de archivos → DoS:

• Sobrescribir model.py / config.pbtxt de otro modelo → el modelo falla al cargar → 503
• Tar que contiene un bin/activate grande o FIFO /tmp/fifo → cuelga el hilo pb_env.cc → UNAVAILABLE
• Inundar load_model con tar ../../dev/zero (infinito) → OOM

Este repo se centra en la escritura de archivos como evidencia del traversal; el DoS puede ampliarse con un tar que contenga 1/model.py con bucle infinito.

10. Mitigación

1. Parche: 26.06 (server v2.70.0, core r26.06) — IsChildPathEscapingParentPath + ARCHIVE_EXTRACT_SECURE_NODOTDOT.
2. Workaround 26.05:
   • No exponer 8000/8001 a internet (proxy inverso + autenticación)
   • WAF que bloquee .. y %2f en URL y EXECUTION_ENV_PATH
   • Deshabilitar EXECUTION_ENV_PATH del backend Python si no es necesario
3. Detección: docker logs tritonserver-test | grep "Path contains\|failed to poll.*%2f"

11. Estructura del Repo (Después de la Limpieza)

Eliminados: exploit_cve_*.py, poc_zipslip_simple.py, check_mode.py, test_http_grpc_blocked.py, cleanup_poc.py, test_poc.ps1, null, model_repository/zipslip_*, /tmp/poc_marker.

12. Referencias y Cronología

• Boletín NV 5865: https://github.com/NVIDIA/product-security/tree/main/2026/5865 (5865.md, CVE-2026-47627.json)
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-47627 (En Análisis)
• Commits de fix core r26.06: dcb315d (Modernize Child Path), 72f3d9b (test de child path), e520f8c7 (test zipslip), 50830ba/66f09f8 (ValidateModelName)
• Fix server r26.06: v2.70.0 (690f9dd)
• Crédito: Martin Brodeur

Notas

Este PoC es para educación y laboratorio cerrado. No expongas 8000/8001 sin autenticación. Siempre ejecuta exploit.py --keep y luego docker exec tritonserver-test rm -f /tmp/poc_marker y Remove-Item -Recurse model_repository/poc_exploit después de la demo.