1. Résumé du CVE

Note honnête : La description CNA ne mentionne que path traversal → DoS sans détails. Ce writeup reconstruit l'emplacement du bug via le diff r26.05..r26.06 et des tests directs dans le conteneur 26.05-py3.

2. Environnement de laboratoire

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

Compose toujours explicit (déjà patché dans ce repo) :

run_triton.bat:10, run_triton.ps1:11, run_triton.sh:12 sont également en explicit.

Mode Triton :

• NONE (défaut upstream) → chargement unique au démarrage, POST /v2/repository/models/.../load → 503, nécessite un redémarrage pour charger un nouveau modèle.
• POLL → scanne le repo chaque seconde, chargement auto, bloque toujours le chargement explicite.
• EXPLICIT (ce repo) → pas de scan, mais ouvre gRPC load_model / POST /load → PoC sans redémarrage via gRPC.

Ports : | 8000 | HTTP REST | v2/health, v2/models, v2/repository | | 8001 | gRPC | RepositoryModelLoad, ModelInfer | | 8002 | Metrics | Prometheus |

Modèles initiaux :

Démarrage rapide :

3. Anatomie de la vulnérabilité

• Si join sans canonicalize ou avec un contrôle rfind(parent,0)==0 incorrect (correspondance partielle /models vs /models_evil), alors ../ peut s'échapper.
• DoS se produit si le fichier traversé est un FIFO, /dev/zero, /proc/self/mem, ou un tar contenant ../../ qui écrase des fichiers système → blocage / OOM / crash.

Trois questions de recherche (du rapport initial) :

1. Où l'utilisateur contrôle-t-il le chemin ? → model_name dans gRPC RepositoryModelLoad, EXECUTION_ENV_PATH tar entry, override file:, TRITON_BATCH_STRATEGY_PATH.
2. Comment le chemin est-il utilisé ? → posixpath.join(repo, model_name) / temp_dir + "/" + file_name + IsChildPathEscapingParentPath.
3. Quel est l'impact ? → DoS via épuisement des ressources / blocage. Dans ce repo, une écriture de fichier vers /tmp/poc_marker est prouvée.

4. Analyse de la cause racine (Diff 26.05 → 26.06)

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

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

   root@kitploit:~

   // VULN (r26.05):
   absolute_child.rfind(absolute_parent,0) != 0
   // → bug de correspondance partielle : le préfixe "/models" de "/models_evil/file" est considéré comme interne
   
   // CORRIGÉ (r26.06):
   canonical_child.find(canonical_parent,0)==0 &&
   ((child.size() > parent.size() && child[parent.size()]=='/') || child.size()==parent.size())
   // → doit avoir '/' après le préfixe, "/models_evil" est maintenant correctement externe
   

   Utilisé dans src/backend_model.cc:196 (TRITON_BATCH_STRATEGY_PATH) et src/model_repository_manager/model_repository_manager.cc:162 (file:).

2. src/model_repository_manager/model_repository_manager.cc:62 ValidateModelName — core#472/#481 (mars 2026, déjà dans 26.05 mais renforcé dans 26.06) :

   root@kitploit:~

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

   C'est ce qui fait que gRPC load_model('../tmp/pwn') → 400 INVALID_ARGUMENT dans 26.05 (déjà bloqué). Mais %2f (/ encodé) passe car ce n'est pas un / littéral → 500 poll littéral.

3. python_be.cc:292 EXECUTION_ENV_PATH — e520f8c7 test zipslip_test.py : Le tar est extrait sans contrôle de .. / chemin absolu. L'entrée ../../poc_marker de /models/poc_exploit/malicious_env.tar.gz est extraite vers /tmp/poc_marker (hors du répertoire du modèle). Correctif dans 26.06 : utilisation de ARCHIVE_EXTRACT_SECURE_NODOTDOT|NOABSOLUTEPATHS + contrôle IsChildPathEscapingParentPath.

Repo server (r26.05..r26.06) : uniquement sagemaker_server.cc:1027 (contrôle RE2::FullMatch) + http_server.cc:2440 (atoi→stoi), pas le chemin de ce CVE.

Conclusion : Le chemin model_name via HTTP/gRPC était déjà bloqué dans 26.05 par ValidateModelName, mais le Zip-Slip tar ne l'était pas — c'est ce qui est exploité par le PoC de ce repo.

5. Chemins d'exploitation : lesquels sont réellement vulnérables ?

L'analogie 500 vs 400 dans l'ancien writeup était erronée : 500 = fichier inexistant (porte absente), 400 = rejeté par validation (porte verrouillée). Aucun des deux n'entre. Seul 200 + fichier dans /tmp est une preuve.

6. PoC principal : Zip-Slip via EXECUTION_ENV_PATH

Idée : Le paramètre Python backend EXECUTION_ENV_PATH pointe vers $$TRITON_MODEL_DIRECTORY/malicious_env.tar.gz. Lors du load_model('poc_exploit'), le backend pb_env.cc:292 extrait le tar sans assainissement. L'entrée ../../poc_marker s'échappe de .../poc_exploit/ vers /tmp/poc_marker.

Étapes du PoC (automatisées dans scripts/exploit.py:28 & exploit.ps1:20) :

1. Copier echo_python → poc_exploit (scripts/exploit.py:35)
2. Ajouter config.pbtxt (scripts/exploit.py:40) :
   root@kitploit:~

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

3. Créer le 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. Déclencher gRPC load_model('poc_exploit') (scripts/exploit.py:60) — sans redémarrage car explicit.
5. Vérifier docker exec tritonserver-test cat /tmp/poc_marker → pwned (scripts/exploit.py:81)

7. Comment exécuter le PoC (One-Click)

Prérequis : Docker, image 26.05-py3 déjà lancée avec docker compose up -d (le repo est déjà en explicit).

Python (sans redémarrage, via gRPC) :

PowerShell :

Revenir à MODE_NONE (si vous voulez le défaut upstream) :

Test de blocage (doit renvoyer 400/404/500, pas 200) :

8. Preuve de traversal (pas un faux 500)

Vulnérable (26.05) — sortie de exploit.py :

Vérification :

Corrigé (26.06) — attendu :

HTTP/gRPC .. doit renvoyer 400, pas 500 :

9. Impact DoS

Le CNA mentionne DoS, mais ce Zip-Slip peut faire une écrasement de fichier → DoS :

• Écraser model.py / config.pbtxt d'un autre modèle → échec de chargement du modèle → 503
• Tar contenant un gros bin/activate / FIFO /tmp/fifo → blocage du thread pb_env.cc → UNAVAILABLE
• Inondation de load_model avec un tar ../../dev/zero (infini) → OOM

Ce repo se concentre sur l'écriture de fichier comme preuve de traversal ; le DoS peut être étendu avec un tar contenant 1/model.py en boucle infinie.

10. Atténuations

1. Correctif : 26.06 (server v2.70.0, core r26.06) — IsChildPathEscapingParentPath + ARCHIVE_EXTRACT_SECURE_NODOTDOT.
2. Contournement 26.05 :
   • Ne pas exposer 8000/8001 sur Internet (reverse proxy + authentification)
   • WAF bloquant .. & %2f dans les URL & EXECUTION_ENV_PATH
   • Désactiver le backend Python EXECUTION_ENV_PATH si non nécessaire
3. Détection : docker logs tritonserver-test | grep "Path contains\|failed to poll.*%2f"

11. Structure du repo (après nettoyage)

Supprimés : 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. Références & chronologie

• Bulletin 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 attente d'analyse)
• Commits de correctif core r26.06 : dcb315d (Modernize Child Path), 72f3d9b (test child path), e520f8c7 (test zipslip), 50830ba/66f09f8 (ValidateModelName)
• Correctif server r26.06 : v2.70.0 (690f9dd)
• Crédit : Martin Brodeur

Notes

Ce PoC est destiné à l'éducation & un laboratoire fermé. N'exposez pas 8000/8001 sans authentification. Toujours utiliser exploit.py --keep puis docker exec tritonserver-test rm -f /tmp/poc_marker & Remove-Item -Recurse model_repository/poc_exploit après la démonstration.