1. CVE-Zusammenfassung

Ehrlicher Hinweis: Die CNA-Beschreibung nennt nur path traversal → DoS ohne Details. Dieses Writeup rekonstruiert die Bug-Stelle über den Diff r26.05..r26.06 und direkte Tests im Container 26.05-py3.

2. Laborumgebung

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

Compose ist immer explicit (in diesem Repo bereits gepatcht):

run_triton.bat:10, run_triton.ps1:11, run_triton.sh:12 sind ebenfalls bereits explicit.

Triton-Modi:

• NONE (Standard-Upstream) → lädt einmal beim Start, POST /v2/repository/models/.../load → 503, Neustart erforderlich, um neue Modelle zu laden.
• POLL → scannt das Repo jede Sekunde, lädt automatisch, blockiert weiterhin explizites Laden.
• EXPLICIT (dieses Repo) → scannt nicht, öffnet aber gRPC load_model / POST /load → PoC ohne Neustart über gRPC.

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

Ausgangsmodelle:

Schnellstart:

3. Anatomie der Schwachstelle

• Wenn join ohne canonicalize oder eine falsche rfind(parent,0)==0-Prüfung (Teiltreffer /models vs /models_evil) verwendet wird, kann ../ ausbrechen.
• DoS tritt auf, wenn die traversierte Datei ein FIFO, /dev/zero, /proc/self/mem ist oder das Tar ../../-Einträge enthält, die Systemdateien überschreiben → Hang / OOM / Crash.

Drei Forschungsfragen (aus dem ersten Bericht):

1. Wo kontrolliert der Benutzer den Pfad? → model_name in gRPC RepositoryModelLoad, EXECUTION_ENV_PATH-Tar-Eintrag, file:-Override, TRITON_BATCH_STRATEGY_PATH.
2. Wie wird der Pfad verwendet? → posixpath.join(repo, model_name) / temp_dir + "/" + file_name + IsChildPathEscapingParentPath.
3. Welche Auswirkung hat das? → DoS über Ressourcenerschöpfung / Hang. In diesem Repo wird Datei-Schreiben nach /tmp/poc_marker nachgewiesen.

4. Root-Cause-Analyse (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 bei Teiltreffer: "/models"-Präfix von "/models_evil/file" wird als inside betrachtet
   
   // FIXED (r26.06):
   canonical_child.find(canonical_parent,0)==0 &&
   ((child.size() > parent.size() && child[parent.size()]=='/') || child.size()==parent.size())
   // → muss '/' nach dem Präfix sein, "/models_evil" ist jetzt korrekt outside
   

   Verwendet in src/backend_model.cc:196 (TRITON_BATCH_STRATEGY_PATH) und src/model_repository_manager/model_repository_manager.cc:162 (file:).

2. src/model_repository_manager/model_repository_manager.cc:62 ValidateModelName — core#472/#481 (März 2026, bereits in 26.05, aber in 26.06 verschärft):

   root@kitploit:~

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

   Das bewirkt, dass gRPC load_model('../tmp/pwn') → 400 INVALID_ARGUMENT in 26.05 (bereits blockiert). Aber %2f (encodiertes /) kommt durch, weil es kein literales / ist → 500-Literal-Poll.

3. python_be.cc:292 EXECUTION_ENV_PATH — e520f8c7 Test zipslip_test.py: Tar wird ohne Prüfung auf .. / absolute Pfade extrahiert. Eintrag ../../poc_marker aus /models/poc_exploit/malicious_env.tar.gz wird nach /tmp/poc_marker extrahiert (außerhalb des Modellverzeichnisses). Fix in 26.06: Verwendung von ARCHIVE_EXTRACT_SECURE_NODOTDOT|NOABSOLUTEPATHS + Prüfung IsChildPathEscapingParentPath.

Repo server (r26.05..r26.06): nur sagemaker_server.cc:1027 (RE2::FullMatch-Prüfung) + http_server.cc:2440 (atoi→stoi), nicht der Pfad dieser CVE.

Fazit: Der model_name-Pfad über HTTP/gRPC ist bereits in 26.05 durch ValidateModelName blockiert, aber der Zip-Slip im Tar ist es nicht — genau das nutzt der PoC dieses Repos aus.

5. Exploit-Pfade: Welche sind wirklich betroffen?

Die Analogie 500 vs 400 im alten Writeup war falsch: 500 = Datei existiert nicht (Tür existiert nicht), 400 = durch Validierung abgelehnt (Tür ist verschlossen). Beides führt nicht hinein. Nur 200 + Datei in /tmp ist der Beweis.

6. Haupt-PoC: Zip-Slip über EXECUTION_ENV_PATH

Idee: Der Python-Backend-Parameter EXECUTION_ENV_PATH zeigt auf $$TRITON_MODEL_DIRECTORY/malicious_env.tar.gz. Beim load_model('poc_exploit') extrahiert das Backend pb_env.cc:292 das Tar ohne Sanitisierung. Der Eintrag ../../poc_marker entkommt aus .../poc_exploit/ nach /tmp/poc_marker.

PoC-Schritte (automatisiert in scripts/exploit.py:28 & exploit.ps1:20):

1. Kopiere echo_python → poc_exploit (scripts/exploit.py:35)
2. Füge config.pbtxt an (scripts/exploit.py:40):
   root@kitploit:~

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

3. Erstelle 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. Trigger gRPC load_model('poc_exploit') (scripts/exploit.py:60) — ohne Neustart, weil explicit.
5. Verifiziere docker exec tritonserver-test cat /tmp/poc_marker → pwned (scripts/exploit.py:81)

7. So führst du den PoC aus (One-Click)

Voraussetzungen: Docker, Image 26.05-py3 bereits mit docker compose up -d gestartet (Repo ist bereits explicit).

Python (ohne Neustart, über gRPC):

PowerShell:

Zurück zu MODE_NONE (falls Standard-Upstream gewünscht):

Blockiertest (muss 400/404/500 sein, nicht 200):

8. Traversal-Nachweis (Kein Fake-500)

Verwundbar (26.05) — exploit.py-Ausgabe:

Verifizierung:

Gepatcht (26.06) — erwartet:

HTTP/gRPC .. muss 400 sein, nicht 500:

9. DoS-Auswirkungen

CNA schreibt DoS, aber dieser Zip-Slip kann Datei-Überschreiben → DoS bewirken:

• Überschreibe model.py / config.pbtxt anderer Modelle → Modell lädt nicht → 503
• Tar mit großem bin/activate / FIFO /tmp/fifo → Thread-Hang in pb_env.cc → UNAVAILABLE
• Flood load_model mit Tar ../../dev/zero (unendlich) → OOM

Dieses Repo konzentriert sich auf Datei-Schreiben als Traversal-Nachweis; DoS kann mit einem Tar erweitert werden, das 1/model.py mit einer Endlosschleife enthält.

10. Mitigation

1. Patch: 26.06 (server v2.70.0, core r26.06) — IsChildPathEscapingParentPath + ARCHIVE_EXTRACT_SECURE_NODOTDOT.
2. Workaround 26.05:
   • 8000/8001 nicht ins Internet exponieren (Reverse-Proxy + Auth)
   • WAF blockt .. & %2f in URLs & EXECUTION_ENV_PATH
   • Python-Backend EXECUTION_ENV_PATH deaktivieren, falls nicht benötigt
3. Erkennung: docker logs tritonserver-test | grep "Path contains\|failed to poll.*%2f"

11. Repo-Struktur (Nach der Bereinigung)

Entfernt: 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. Referenzen & Zeitplan

• 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 (Awaiting Analysis)
• Fix-Commits core r26.06: dcb315d (Modernize Child Path), 72f3d9b (child path test), e520f8c7 (zipslip test), 50830ba/66f09f8 (ValidateModelName)
• Fix server r26.06: v2.70.0 (690f9dd)
• Credit: Martin Brodeur

Hinweise

Dieser PoC dient Bildungszwecken & geschlossenen Laboren. Exponiere 8000/8001 nicht ohne Auth. Führe nach der Demo immer exploit.py --keep und dann docker exec tritonserver-test rm -f /tmp/poc_marker & Remove-Item -Recurse model_repository/poc_exploit aus.