Chainguard hat am 13. Oktober einen Fehler in vLLM beschrieben, durch den eine Anfrage die Ausgabe einer anderen Anfrage beeinflussen konnte. Betroffen waren Versionen vor 0.31.0, wenn unterschiedliche Clients dieselbe Modellinstanz nutzten. Die Schwachstelle war seit Mai als gewöhnlicher Fehler im öffentlichen Issue-Tracker bekannt; erst die spätere Untersuchung machte ihre Sicherheitsfolge deutlich.
Eine alte Token-Beschränkung blieb im wiederverwendeten Request-Slot
vLLM kann mit dem Parameter allowedtokenids festlegen, welche Tokens eine Modellantwort enthalten darf. Der Server verwaltet solche Einschränkungen für gleichzeitig laufende Anfragen in einer gemeinsamen Tabelle. Beim Zusammenfassen und Wiederverwenden von Request-Slots blieb in der betroffenen Implementierung eine Einschränkung zurück. Eine nachfolgende Anfrage konnte dadurch unbeabsichtigt unter der Token-Auswahl einer früheren Anfrage ausgeführt werden.
Chainguard demonstrierte eine normale, erfolgreich abgeschlossene Antwort, deren Inhalt nicht zur gestellten Frage passte. Die Forscher reproduzierten den Effekt in drei von drei kontrollierten Versuchen. Der Angreifer konnte laut Bericht weder einen bestimmten anderen Client auswählen noch dessen Prompt lesen. Nachgewiesen ist eine Verletzung der Integrität von Antworten, keine beliebige Datenextraktion.
Für Anwendungen, die Modellantworten ohne menschliche Kontrolle als Klassifikation oder Entscheidungssignal weiterverwenden, ist dieser Unterschied relevant. Eine technisch erfolgreiche API-Antwort garantiert nicht, dass die zugehörigen Generierungsbeschränkungen aus der richtigen Anfrage stammen.
Der Sicherheitsbefund entstand aus einer Laufzeitprüfung
Chainguard beschreibt einen Mythos-basierten Prüf-Harness, der Projekte aus Quellcode in isolierten Micro-VMs startet und reale Programmabläufe testet. Mögliche Befunde werden auf einer frischen Instanz reproduziert und anschließend von Ingenieuren überprüft. Nach Unternehmensangaben wurden so mehr als 65 Projekte untersucht und über 680 Befunde validiert; diese Zahlen sind nicht unabhängig auditiert.
Der konkrete vLLM-Fehler wurde bereits am 28. Mai als Issue gemeldet. Chainguard informierte die Maintainer am 23. September über die Sicherheitsfolge. Die Korrektur erschien am 2. Oktober mit vLLM 0.31.0; das Security Advisory folgte am 6. Oktober. Das Projekt bewertet die einzelne Schwachstelle als Low.
Mandantenisolation muss unterhalb des Modells greifen
Für Betreiber gemeinsam genutzter Inferenzserver folgt daraus eine überprüfbare Anforderung: Request-spezifische Einschränkungen dürfen nach dem Recycling eines Slots nicht für andere Clients gelten. vLLM dokumentiert außerdem, dass eine gemeinsame Engine keine vollständige Sicherheitsisolation zwischen Mandanten bietet. Unabhängige Engines für nicht gegenseitig vertrauenswürdige Kunden und ein vorgeschaltetes Gateway mit einheitlicher Authentifizierung reduzieren diese Angriffsfläche.
Quellen: Chainguard, 13.10.2026: https://www.chainguard.dev/de-DE/unchained/the-first-disclosure-from-our-mythos-harness ; vLLM Security Advisory GHSA-6cxc-2vcg-w5qc: https://github.com/vllm-project/vllm/security/advisories/GHSA-6cxc-2vcg-w5qc