Wenn das Modell die Antwort des Nachbarn ausliefert

Am 11. August 2026 hat das vLLM-Projekt zwei Sicherheitshinweise veröffentlicht. Der eine ist Routine. Der andere beschreibt etwas, das in der Liste der üblichen Verwundbarkeiten keine saubere Schublade hat: Die Antwort eines Nutzers kann in der Antwort eines anderen landen — ohne dass jemand angreift.

Aufgefallen ist uns die Meldung nicht über die Fachpresse, sondern über den Warndienst des BSI, der sie drei Tage später in einer Advisory-Welle mitführte. Das ist bereits die erste Lehre dieses Falls, aber nicht die interessanteste.

Eine Zeile CUDA-Arithmetik

Der technische Kern von GHSA-7m6h-x95x-82q5 (CVE-2026-73558) ist unspektakulär und gerade deshalb lehrreich. Im Aktivierungs-Kernel act_and_mul_kernel steht der Ausdruck blockIdx.x * 2 * d. Bei hinreichend großem Batch und hinreichend langer Sequenz überläuft dieser Ausdruck den 32-Bit-Wertebereich. Der Kernel greift danach auf einen falschen Speicherbereich zu — und zwar auf den einer anderen Anfrage im selben Batch.

Die Melder haben das nicht theoretisch hergeleitet, sondern reproduziert: mit meta-llama/Llama-3.2-1B-Instruct (Dimension d = 8192), Batchgröße 17 und 16.384 Token Sequenzlänge. Das Ergebnis war kein subtiler Datenrest, sondern der Extremfall — die letzte Antwort im Batch war eine exakte Kopie der ersten. Bemerkenswert ist auch der Weg dorthin: Der Überlauf war zuerst als gewöhnlicher Korrektheits-Bug gemeldet worden. Erst die spätere Sicherheitsanalyse zeigte, dass ein Rechenfehler hier eine Mandantengrenze durchschlägt.

Warum CVSS 5.3 hier in die Irre führt

Das Advisory ist mit CVSS 5.3 („medium") bewertet, Vektor AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N. Der niedrige Wert kommt vor allem aus der hohen Angriffskomplexität: Wer den Leak gezielt provozieren will, muss im selben Batch landen wie sein Opfer und eine passende Dimension treffen — laut Advisory tritt der Effekt auf, wenn 2³² durch d teilbar ist.

Diese Bewertung beantwortet die Frage „Wie schwer ist ein gezielter Angriff?". Für den Betrieb einer selbst gehosteten Inferenz-Lane ist aber eine andere Frage entscheidend: Wie wahrscheinlich ist der Unfall? Und dafür braucht es keinen Angreifer, sondern nur zwei gleichzeitige Nutzer, eine übliche Batchgröße und ein Modell mit einer Zweierpotenz als Zwischendimension — was auf viele gängige Architekturen zutrifft.

Genau hier liegt der Unterschied zwischen einer gemieteten API und dem eigenen Server. Bei einem API-Anbieter ist die Mandantentrennung dessen Problem und dessen Haftung. Wer selbst hostet, hat sie übernommen — und stellt womöglich zum ersten Mal fest, dass sie nicht durch eine Zugriffskontrolle verläuft, sondern durch Kernel-Code, den niemand im Haus je gelesen hat.

Der Selbsttest — und warum die Versionsnummer nicht reicht

Wir betreiben drei Inferenz-Hosts und haben alle drei gegen die beiden Meldungen geprüft. Das Ergebnis war nicht das erwartete Ampelbild:

• Die Vision-Lane läuft auf vLLM 0.27.1 — versorgt, für beide Advisories.
• Die Chat-Lane läuft auf 0.25.1.
• Die Embedding- und Rerank-Container laufen auf 0.20.2.

Nach reiner Versionslogik wären die letzten beiden betroffen. Die Prüfung des Codepfads ergibt ein anderes Bild. Das zweite Advisory, GHSA-cqm8-jxg6-fqfq, nennt pauschal < 0.27.0 als verwundbar — beschreibt aber eine Verwechslung im DeepStream-Video-Backend, das laut Advisory-Text erst in Version 0.26.0 eingeführt wurde. Auf einer 0.25.1 gibt es dieses Backend nicht. Der Befund läuft dort ins Leere.

Beim Cross-User-Leak ist die Lage umgekehrt unangenehm: Das Advisory nennt als betroffenen Bereich < 0.21.0, als Fix aber >= 0.27.0. Beides zusammen ergibt keinen Sinn. Wer sich strikt an das Versionsfeld hält, erklärt eine 0.25.1 für unbetroffen; wer sich an das Fix-Feld hält, für betroffen. Diese Widersprüchlichkeit ist kein Detail am Rand — sie ist der Grund, warum automatisierte Versionsabgleiche hier still das Falsche sagen.

Was jetzt zu tun ist

Auf 0.27.x heben, wo mehrere Nutzer dieselbe Lane teilen. Das ist die einzige vollständige Antwort auf den Leak; einen Workaround gibt es nicht, weil das Verhalten im Kernel steckt und nicht in einer Konfiguration.

Einmandantige Lanes ehrlich einordnen. Wenn eine Lane nachweislich nur einen Nutzer bedient, ist der Cross-User-Leak für sie kein Risiko. Das ist ein zulässiges Ergebnis — es muss nur belegt und nicht bloß angenommen sein, denn ein vorgeschalteter Gateway macht aus vielen Nutzern still einen einzigen technischen Aufrufer.

Batch-Isolation dokumentieren. Wer eine Datenschutz-Folgenabschätzung für eine lokale KI-Lane schreibt, beschreibt darin üblicherweise Netztrennung, Verschlüsselung und Zugriffsrechte. Die Frage, welche Anfragen im selben Batch landen können, gehört ab sofort in dieselbe Liste — sie ist bei gemeinsam genutzter Inferenz die eigentliche Trennlinie zwischen zwei Nutzern.

Advisory-Feeds direkt lesen. Diese beiden Meldungen kamen bei uns über den CERT-Bund-Warndienst an, nicht über die Fachpresse — dort tauchten sie gar nicht auf. Für selbst gehostete Software ist die Behörden- und Projektebene nicht die langsamere Quelle, sondern die einzige.

Die eigentliche Lektion

Der Fall taugt schlecht als Skandal: mittlere Bewertung, kein Exploit in freier Wildbahn, ein sauberer Fix. Er taugt aber gut als Modell für eine Fehlerklasse, die mit selbst betriebener KI neu ins Haus kommt. Sicherheitsdenken bei klassischer Software fragt, wer worauf zugreifen darf. Bei gemeinsam genutzter Inferenz muss es zusätzlich fragen, wessen Daten im selben Rechenschritt nebeneinander liegen.

Und es lohnt sich, den zweiten Teil dieses Textes ernster zu nehmen als den ersten: Von zwei formal passenden Treffern blieb nach der Prüfung des Codepfads einer übrig. Ein Werkzeug, das nur Versionsnummern vergleicht, hätte beide gemeldet — und beim nächsten Mal glaubt niemand mehr hin.