Das Leck unter der KI-Cloud: Warum ausgerechnet die Inferenz-Software Daten verrät

Darum geht es

Wer ein offenes Modell wie GLM, DeepSeek oder Kimi nicht selbst betreibt, sondern über eine KI-Cloud nutzt, schickt seine Eingaben letztlich an eine Inferenz-Engine. Das ist das Programm, das das Modell auf den Grafikkarten ausführt, Anfragen bündelt und Antworten erzeugt. Die meistgenutzten heißen SGLang, vLLM und TensorRT-LLM. Innerhalb weniger Wochen gab es drei Vorfälle, die jeweils einzeln gemeldet wurden. Im Kern betreffen alle drei diese Schicht zwischen Modell und Nutzer:

Unsere These: Die Software unter vielen KI-Clouds ist schneller gewachsen als ihre Sicherheitskultur. Am deutlichsten zeigt sich das bei SGLang.

14 Lücken, null Antworten: die Bilanz bei SGLang

Wir haben die Hinweise des CERT/CC einzeln geprüft. Das CERT Coordination Center an der Carnegie Mellon University vermittelt zwischen den Entdeckern einer Lücke und den Herstellern. 2026 hat es fünf Hinweise zu SGLang veröffentlicht. Zusammen ergeben sie genau die 14 Lücken, die auch die Analyse von beri.net zählt:

Fast alles folgt einem Grundmuster. SGLang verschickt intern Daten mit Pickle, einem Python-Format, das beim Einlesen beliebigen Code ausführen kann, ungefähr so, als würde man jedes zugeschickte Paket blind auspacken und den Inhalt sofort einschalten. Transportiert werden die Daten über ZeroMQ, eine Nachrichtenbibliothek, deren Sockets hier keine Anmeldung verlangen. Wer den passenden Port erreicht, kann also Code auf dem Server ausführen. Bei CVE-2026-7301 bindet sich der Scheduler laut CERT/CC ab Werk an alle Netzwerkschnittstellen (0.0.0.0). Die Entdecker von Antiproof präzisieren: Im Code selbst steht 127.0.0.1, aber alle Beispiele in der Installationsanleitung verwenden 0.0.0.0.

Zur Reaktionszeit: Orca Security meldete die ersten Lücken am 4. Februar. Weil keine Antwort kam, schrieb CERT/CC am Ende selbst einen Patch-Vorschlag und schaltete die US-Behörde CISA ein, ebenfalls ohne Erfolg. Erst Version 0.5.10 band den Broker an localhost. Beim Fehler mit den Jinja-Vorlagen nutzt der aktuelle Hauptzweig inzwischen eine Sandbox, wie wir im Code nachgesehen haben. Ein Advisory dazu gibt es aber nicht. Auf der Sicherheitsseite von SGLang steht bis heute „keine veröffentlichten Security Advisories“ und „keine Sicherheitsrichtlinie“. Wer SGLang betreibt, erfährt also nicht offiziell, welche Version welche Lücke schließt.

Der wichtigste Schalter steht weiter auf unsicher. CERT/CC empfiehlt, SGLANG_USE_PICKLE_IPC auf „false“ zu setzen. In der Datei environ.py steht heute (13. November) aber immer noch EnvBool(True). Das GitHub-Ticket #29465, mit dem die Voreinstellung umgestellt werden sollte, hat ein Bot am 23. September wegen Inaktivität geschlossen. Der Schritt „Voreinstellung umdrehen“ war da noch gar nicht begonnen. Dazu kommt CVE-2026-93034, das laut Forkast am 7. Oktober öffentlich wurde: Über den msgpack-Pfad bleibt Pickle trotzdem erreichbar, wenn Data-Parallel-Attention mit einer nicht-lokalen --dist-init-addr läuft. Einen Fix gibt es demnach nicht.

Eine mögliche Erklärung liefert die Cloud Security Alliance, allerdings nur als Vermutung: Seit SGLang im Januar 2026 in das Unternehmen RadixArk ausgegliedert wurde, könnten Sicherheitskontakte verloren gegangen sein. Bestätigt hat das niemand. Auffällig ist, dass Cloudflare im September problemlos ein Treffen mit den SGLang-Maintainern bei RadixArk bekam. Große Partner erreichen das Team offenbar, CERT/CC nicht.

Zum Vergleich: vLLM und TensorRT-LLM

Auch vLLM hat schwere Lücken, etwa CVE-2026-22778 mit CVSS 9.8 über manipulierte Video-URLs, behoben in 0.14.1. Der Unterschied liegt im Prozess: Laut seiner Richtlinie veröffentlicht vLLM ein Advisory, sobald der Fix in einem Release steckt. Kritische Lücken werden vorher in einem privaten Fork behoben. Viele Einträge betreffen Abstürze, also Denial of Service. Die vielen Advisories sind deshalb eher ein Zeichen von Transparenz als von besonders schlechtem Code. Die Pickle-Probleme hat übrigens nicht nur SGLang. Oligo Security zeigte im November 2025 unter dem Namen „ShadowMQ“, dass derselbe unsichere ZeroMQ-Pickle-Code von Projekt zu Projekt kopiert wurde. Die SGLang-Datei beginnt laut Oligo wörtlich mit „Adapted from vLLM“. Die anderen Projekte haben den Code inzwischen ersetzt.

Wo „Confidential AI“ prinzipbedingt nicht hilft

NEAR AI wirbt mit privater Inferenz in einem TEE (Trusted Execution Environment). Das ist ein von der Hardware abgeschotteter Bereich, hier mit Intel TDX und H200-GPUs im Confidential-Computing-Modus, in den weder der Server-Betreiber noch das Betriebssystem hineinsehen können. Brave lässt seinen Assistenten Leo laut NEAR AI über diese Infrastruktur laufen. Ob Brave-Nutzer betroffen sind, sagt der Bericht nicht. NEAR AI schreibt selbst:

Confidential Computing schützt Daten vor dem Betreiber und dem Host. Es schützt nicht vor einer Schwachstelle in der Software, die innerhalb der Umgebung läuft.

Daraus ergeben sich drei grundsätzliche Grenzen:

1. Die Engine muss die Daten im Klartext sehen. Auch mit Ende-zu-Ende-Verschlüsselung wird der Prompt in der Enklave entschlüsselt, damit das Modell ihn verarbeiten kann. Wer dort Code ausführt, liest also mit.
2. Attestation beweist die Identität, nicht die Sicherheit. Bei der Attestation weist die Hardware mit einer Signatur nach, welche Software läuft. Eine verwundbare SGLang-Version besteht diesen Test einwandfrei.
3. Mandantentrennung findet in der Engine statt. Der Cloudflare-Fehler wäre in einem TEE genauso passiert, denn der fremde Inhalt im KV-Cache (dem Zwischenspeicher für bereits verarbeitete Textteile) lag im selben Prozess. NEAR AI räumte schon im Oktober ein, dass Präfix-Caches zwischen Kunden geteilt werden und Antwortzeiten verraten können, ob ein Textanfang schon einmal verarbeitet wurde.

Was genau ausgenutzt wurde, bleibt offen. NEAR AI nennt weder eine CVE noch eine Version und hat die Lücke nach eigenen Angaben erst an SGLang gemeldet. Es könnte also eine neue Lücke sein. Tatsächlich abgeflossen sind die Kontodaten von rund 100 Nutzern, die Daten von 18 alten Agenten, die außerhalb des TEE liefen, und die API-Schlüssel zweier Cloud-Kunden. Ob vertrauliche Anfragen tatsächlich gelesen wurden, sagt der Bericht nicht.

Cloudflare und Fireworks: zwei andere Spielarten

Bei Cloudflare war es kein Angriff. Ein Forscher meldete das Problem über HackerOne. GLM-5.3 lief mit 1.048.576 Token Kontext, der KV-Speicher fürs Prefill fasste aber nur 681.280 Token. Zu lange Anfragen markierte SGLang im Modus mit getrenntem Prefill und Decode (Einlesen und Antworten laufen auf verschiedenen GPUs) als abgelehnt, brach sie aber nicht ab. Der Decode-Knoten las dann Speicherseiten, die noch Daten älterer Anfragen enthielten. Der Kunde bekam trotzdem HTTP 200. Der Fehler war upstream schon seit dem 6. Juli als Issue #30233 gemeldet. Ein Prototyp, der jeden KV-Zugriff prüft, hätte das laut Cloudflare abfangen können, war aber Mitte August wegen Stabilitätsproblemen abgeschaltet worden. Cloudflare empfiehlt SGLang 0.5.22 oder neuer.

Fireworks passt nur zum Teil ins Muster. Am 6. Oktober wurden dort interne Zugangsdaten missbraucht, ab dem 23. und 24. Oktober kam ein Angreifer über einen gehackten Cloud-Zulieferer auf Entwicklungsrechner. Fireworks ordnet die Täter einer Gruppe zu, die mit LLMjacking Geld verdient, also mit gestohlenen KI-Zugängen handelt. Auf die eigentliche Inferenz habe es laut Fireworks keine Auswirkungen gegeben, sie laufe standardmäßig ohne Datenspeicherung. Notion widerspricht dem zumindest indirekt. Notion hatte vertraglich „Zero Data Retention“ zugesichert bekommen, also keinerlei Speicherung, und fand dennoch gespeicherte Daten von den genutzten Endpunkten. Betroffen sind laut Notion weniger als 1 % der Workspaces. Cursor nennt Fireworks nur als Kunden, mit dem man zusammenarbeite. Dass Cursor-Daten betroffen sind, ist nicht belegt.

Checkliste für Selbsthoster

• Bestandsaufnahme: Alle SGLang-Prozesse erfassen, auch auf Notebooks und Testrechnern, jeweils mit Version und den Netzwerkschnittstellen, an denen sie lauschen.
• Pickle abschalten: SGLANG_USE_PICKLE_IPC=false setzen und testen, ob alles weiter läuft. --dist-init-addr auf Loopback binden (wegen CVE-2026-93034).
• Nichts an 0.0.0.0: Scheduler-, Broker- und ZeroMQ-Ports nur intern erreichbar machen und die Netze segmentieren.
• Ungenutzte Endpunkte sperren: Etwa /v1/rerank, das Laden von LoRA-Adaptern, /update_weights_from_disk und /server_info. Nie ohne API-Schlüssel betreiben.
• Optionen meiden: --enable-custom-logit-processor und DUMPER_SERVER_PORT nur einschalten, wenn wirklich nötig.
• Modelle prüfen: GGUF- und .bin-Dateien nur aus vertrauenswürdiger Quelle laden.
• Aktualisieren: Mindestens Version 0.5.22. Weil es keine Advisories gibt, Changelogs und CERT/CC selbst beobachten.
• Härten: Ausgehenden Verkehr beschränken, nicht als root laufen lassen, Logs nach Schlüsseln durchsuchen.

Fragen an den eigenen Modell-Host

1. Welche Engine in welcher Version verarbeitet unsere Anfragen?
2. Wie schnell spielt ihr kritische CVEs ein, und lehnt eure Attestation Builds mit bekannten Lücken ab?
3. Ist Pickle-IPC abgeschaltet, und sind interne Sockets vom Netz getrennt?
4. Werden KV- oder Präfix-Caches zwischen Kunden geteilt?
5. Wie stellt ihr „Zero Data Retention“ technisch sicher, auch bei Unterauftragnehmern und Zulieferern?
6. Bekommen wir zu jeder attestierten Umgebung eine Liste der Komponenten mit Versionen?

Einordnung

Belegt ist: SGLang hat 2026 mindestens 14 von CERT/CC dokumentierte Lücken gesammelt, keine war bei Veröffentlichung gepatcht, und der zentrale unsichere Schalter steht ab Werk weiter auf „an“. Nicht belegt ist, dass NEAR AI genau über eine dieser Lücken angegriffen wurde, und Fireworks hatte mit der Engine nichts zu tun. Das Muster ist trotzdem eindeutig. Die Inferenz-Schicht ist zum Engpass für Vertrauen geworden, und das umso mehr, je mehr offene Modelle bei Hostern laufen, die alle dieselbe Software einsetzen.

Unsere Einschätzung: TEEs und Verträge mit „Zero Data Retention“ verschieben das Vertrauen, sie ersetzen es nicht. Am Ende hängt alles an einem Python-Prozess, der Prompts im Klartext sieht. Solange SGLang kein geregeltes Verfahren für Sicherheitsmeldungen hat, sollten Firmen die Version der Engine so ernst nehmen wie die Wahl des Modells. Mit vLLM gibt es eine Alternative mit nachvollziehbarem Prozess, auch wenn sie nicht fehlerfrei ist.