- vLLM 0.14.1 enthält in zwei Modell-Implementierungen hartcodiertes trust_remote_code=True — User-Einstellung wird IGNORIERT.
- Angreifer bauen ein bösartiges HuggingFace-Modell und bekommen RCE auf jedem vLLM-Host, der dieses Modell lädt.
- Veröffentlicht am 28. Mai 2026. Patch in vLLM 0.14.2 erwartet — aktuell HOTFIX nötig.
- Sofortmaßnahme: HuggingFace-Modelle nur aus vertrauenswürdigen Repos laden, Network-Egress vom vLLM-Container kappen.
Du betreibst lokale Sprachmodelle mit vLLM? Dann muss DEIN Inference-Stack JETZT auf den Prüfstand. Eine am 28. Mai 2026 offengelegte Lücke zeigt: vLLM 0.14.1 hat in zwei Modell-Implementierungs-Dateien trust_remote_code=True hartcodiert — und übersteuert damit jeden Sicherheitswunsch der User.
Die Folge: Wer ein präpariertes HuggingFace-Modell lädt, gibt dem Modell-Autor freie Bahn zur Code-Ausführung auf dem Host. Klassische Remote Code Execution, getarnt als simples Sprachmodell.
Warum ist das so brisant?
trust_remote_code ist eigentlich ein bewusster Sicherheits-Hebel: Wenn du ein HuggingFace-Modell mit eigenem Python-Code lädst, sollst du erst zustimmen, bevor der Code läuft. Das ist der Schutz vor Modellen, die ihre Inferenz-Logik per Backdoor erweitern.
vLLM hat diesen Hebel in zwei Dateien überschrieben. Auch wenn du in deinem Service-Code trust_remote_code=False setzt: Die hartcodierte True-Einstellung gewinnt.
Wer ist betroffen?
Jeder vLLM-0.14.1-Host. Das schließt Selbst-Hoster mit GPU-Boxen, Cloud-Inferenz-Stacks auf RunPod/Vast.ai und kommerzielle KI-Plattformen ein. Wer eine Modell-Bibliothek wie HuggingFace-Hub integriert hat, ist potenziell offen.
Sofortmaßnahmen — JETZT umsetzen
1. Downgrade auf vLLM 0.13.x oder Hotfix mit gepatchtem Modell-Code installieren.
2. HuggingFace-Modelle ausschließlich aus internen, verifizierten Repos laden. Keine fremden Repos, keine Forks ohne Code-Review.
3. Network-Egress vom vLLM-Container blocken. Wenn das Modell raustelefonieren will, muss die Firewall stoppen.
4. AppArmor/SELinux-Profile aktivieren — der Modell-Code soll keinen Zugriff auf Secrets, Sockets oder andere Container haben.
Längerfristig — Inferenz-Härtung
Nutze separate User-Namespaces für vLLM-Worker. Schalte den HuggingFace-Hub-Auto-Download ab und verteile Modelle über ein internes Artifact-Repo. Logge alle Modell-Lade-Events in dein SIEM.
Häufige Fragen
Bin ich betroffen, wenn ich nur Standard-LLMs wie Llama oder Mistral lade?
Standard-Modelle sind in den meisten Fällen sicher, weil sie keinen modul-spezifischen Code mitbringen. Die Lücke wird gefährlich, sobald jemand ein präpariertes Modell mit custom modeling_*.py einschleust.
Was passiert, wenn ich nicht patchen kann?
Setze starke Container-Isolation um vLLM. AppArmor, SELinux, drop_capabilities. Sperre Netzwerk-Egress ausgehend. Lade Modelle nur aus internen Repos. Das ist Schadensbegrenzung — ersetzt aber nicht den Patch.
Gilt das auch für vLLM 0.14.0 oder 0.13.x?
Die hartcodierte Einstellung wurde in 0.14.1 eingeführt. Ältere Versionen sind nicht direkt betroffen, haben aber andere bekannte Lücken. Die sauberste Lösung ist der Patch auf 0.14.2 sobald verfügbar.
Wie erkenne ich, ob mein vLLM kompromittiert wurde?
Prüfe Audit-Logs auf ungewöhnliche Subprozesse vom vLLM-User, ungewöhnliche Netzwerk-Verbindungen und neue Cron-Jobs. Tools wie Falco oder osquery helfen bei der laufenden Erkennung.