Die US-Cybersicherheitsbehörde CISA hat die GPUStack-Lücke CVE-2026-102895 am 9. November in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Der Fehler erlaubt es Angreifern, sich ohne Zugangsdaten als Administrator eines GPUStack-Servers auszugeben – mit Zugriff auf Benutzer, Modelle, Worker-Zugangsdaten und Cloud-Schlüssel bis hin zur Codeausführung auf den GPU-Hosts. Betroffen sind alle Versionen vor 2.2.0. US-Bundesbehörden müssen bis zum 12. November reagieren. Wer GPUStack für den Betrieb eigener KI-Modelle nutzt, sollte jetzt prüfen, welche Version läuft und wie der Server erreichbar ist.
CVE-2026-102895: Was hinter der GPUStack-Lücke steckt
GPUStack ist ein quelloffener GPU-Cluster-Manager unter Apache-2.0-Lizenz. Teams verteilen damit große Sprachmodelle, Bild- und Audiomodelle über Inferenz-Engines wie vLLM oder SGLang auf mehrere GPU-Server und stellen sie über eine OpenAI-kompatible API bereit. Seit Version 2.2.0 kann GPUStack außerdem GPU-Instanzen auf Abruf bereitstellen, die per SSH erreichbar sind. Damit ist ein GPUStack-Server oft die zentrale Steuerstelle für teure Hardware, Modellgewichte und API-Schlüssel.
Laut dem Sicherheitshinweis GHSA-gj9m-f8ph-pmhr der Entwickler liegt der Fehler in der Funktion get_current_user in gpustack/api/auth.py. Sie behandelte jede Anfrage, deren Absender als Loopback-Adresse (127.0.0.1) galt, automatisch als Anfrage des eingebauten Administrators – sofern die Option force_auth_localhost auf false stand. Genau das war die Voreinstellung. Die Idee dahinter: Wer lokal auf dem Server arbeitet, soll sich nicht anmelden müssen.
Das Problem ist, wie GPUStack den Absender bestimmt hat. Die zuständige Funktion client_ip_getter ließ sich laut Advisory auf zwei Wegen dazu bringen, „127.0.0.1“ zu melden, ohne dass dafür irgendwelche Zugangsdaten nötig waren.
Weg 1: Reverse Proxy auf demselben Host
In einer typischen selbst gehosteten Installation sitzt vor GPUStack ein Reverse Proxy wie Nginx auf demselben Rechner, der Anfragen per proxy_pass http://127.0.0.1:<Port> weiterreicht. Aus Sicht von GPUStack kommt dann jede Anfrage aus dem Internet von der TCP-Gegenstelle 127.0.0.1. Die Folge: Der Zweig für den automatischen Loopback-Administrator griff bei jeder externen Anfrage – ganz ohne präparierten Header. Die Entwickler bezeichnen diese Konstellation ausdrücklich als die „kanonische“ Form des Selbstbetriebs.
Weg 2: Gefälschter X-GPUStack-Real-IP-Header
Zusätzlich konnte ein Angreifer einen eigenen Header X-GPUStack-Real-IP: 127.0.0.1 mitschicken. Auch dann konnte die Anfrage als lokal eingestuft werden. Damit waren auch Installationen ohne vorgeschalteten Proxy gefährdet, sofern der Header auf dem Weg zum Server nicht entfernt wurde.
Welche Folgen ein Angriff haben kann
Beide Wege führen laut Advisory zu vollem, nicht authentifiziertem Administratorzugriff über das Netzwerk. Konkret nennen die Entwickler:
- Benutzer, Modelle, Worker und Konfiguration auflisten und verändern,
- dauerhafte Administrator-API-Schlüssel mit dem Geltungsbereich
["*"]anlegen, die danach von jeder IP-Adresse aus funktionieren, - Zugangsdaten der Worker sowie Geheimnisse von Cloud- und Modellanbietern auslesen,
- über die Admin-Funktion
POST /v2/inference-backends/from-yamleigene Inferenz-Backends anlegen und so Code auf den Worker-Hosts ausführen.
Besonders der zweite Punkt ist heikel: Ein einmal angelegter API-Schlüssel überdauert das Update. Wer nur patcht, aber die vorhandenen Schlüssel nicht prüft, lässt einem Angreifer unter Umständen weiterhin die Tür offen.
Ausnutzung in freier Wildbahn
Das Advisory hält fest, dass die Lücke bereits gegen eine Installation mit Version 2.1.1 ausgenutzt wurde. Angreifer legten dort eigene Inferenz-Backends an, die Reverse Shells starteten – also Verbindungen, über die sie den Rechner fernsteuern konnten. Die aktive Ausnutzung meldete laut Advisory Javier Sixto (ulex.fr). Die Lücke selbst wurde unabhängig voneinander von Nikko Enggaliano, Wei Yunzhou sowie Rui Yang und Haoyu Wang (Johns Hopkins University) gemeldet.
CISA hat CVE-2026-102895 am 9. November zusammen mit drei weiteren Lücken in den KEV-Katalog aufgenommen, darunter die FreeSWITCH-Lücke CVE-2026-116779 und die OpenSSH-Lücke „SSHole“. Die Frist für US-Bundesbehörden endet am 12. November; zusätzlich verlangt CISA eine forensische Prüfung, ob Systeme bereits kompromittiert wurden. Ob die Lücke für Ransomware-Kampagnen genutzt wird, ist laut CISA unbekannt.
Bewertung und Zeitleiste
GitHub hat als CVE-Vergabestelle einen CVSS-3.1-Wert von 9,8 („kritisch“) vergeben: Angriff über das Netzwerk, geringe Komplexität, keine Rechte und keine Nutzerinteraktion nötig. Zugeordnet sind die Schwachstellenklassen CWE-287 (fehlerhafte Authentifizierung), CWE-290 (Umgehung durch Spoofing) und CWE-346 (fehlerhafte Herkunftsprüfung).
Auffällig ist die Zeitleiste. Den Pull Request „remove localhost auto-admin bypass“ (#5346) haben die Entwickler bereits am 19. Mai 2026 zusammengeführt, Version 2.2.0 mit dem Fix erschien am 18. Juni. Das Advisory wurde am 31. Juli veröffentlicht, die CVE-Nummer tauchte am 4. November in der US-Schwachstellendatenbank NVD auf, fünf Tage später folgte der KEV-Eintrag. Wer also seit Monaten auf einer Version vor 2.2.0 hängen geblieben ist, war die ganze Zeit angreifbar – und spätestens seit dem Advisory ist bekannt, wie der Angriff funktioniert. Die aktuelle Version ist 2.3.1 vom 11. November.
Was Betreiber jetzt tun sollten
Der Fix steckt in GPUStack Version 2.2.0. Laut Advisory entfällt dort der automatische Loopback-Administrator vollständig, und der Umgang mit Client-IP- und Weiterleitungs-Headern wurde gehärtet. Für Betreiber ergibt sich daraus eine kurze Liste:
- Update: auf 2.2.0 oder neuer aktualisieren, sinnvollerweise auf die aktuelle Version.
- Übergangslösung: Wer nicht sofort aktualisieren kann, setzt
force_auth_localhost=true, damit auch lokale Anfragen eine Anmeldung brauchen. - Proxy prüfen: Am Netzwerkrand den Header
X-GPUStack-Real-IPaus Client-Anfragen entfernen und sicherstellen, dass externer Verkehr nicht als Loopback ankommt. - Erreichbarkeit einschränken: Die API nicht offen ins Internet stellen, sondern hinter VPN oder vorgeschalteter Authentifizierung betreiben.
Über die Hinweise der Entwickler hinaus empfiehlt sich bei jedem Server, der vor dem Update aus dem Netz erreichbar war, eine Prüfung auf Spuren eines Einbruchs. Das ist eine allgemeine Empfehlung, keine Vorgabe aus dem Advisory: Alle API-Schlüssel und Administratorkonten durchsehen und unbekannte widerrufen, angelegte Inferenz-Backends mit der eigenen Konfiguration abgleichen, ungewöhnliche ausgehende Verbindungen der Worker untersuchen und hinterlegte Cloud- und Anbieter-Zugangsdaten vorsorglich erneuern. Gerade bei GPU-Servern lohnt außerdem ein Blick auf die Auslastung: Fremde Prozesse auf teuren Grafikkarten fallen oft zuerst auf der Rechnung auf.
Einordnung
Die GPUStack-Lücke folgt einem bekannten Muster: Eine Komfortfunktion („lokal ist vertrauenswürdig“) wird zum Einfallstor, sobald sich die Netzwerkumgebung ändert. Vor einen Dienst einen Reverse Proxy zu schalten, gilt eigentlich als gute Praxis – hier hat genau dieser Schritt die Schutzannahme ausgehebelt. Das Advisory formuliert die Lehre selbst: Authentifizierung darf nicht aus der Netzwerkherkunft einer Anfrage abgeleitet werden, und Header mit der „echten“ Client-IP sollten nur von einem vertrauenswürdigen Gateway akzeptiert werden.
Für KI-Infrastruktur ist der Fall ein Warnsignal. Selbst gehostete Werkzeuge für Modellbetrieb wachsen schnell, laufen oft in Forschungs- und Entwicklungsumgebungen mit weniger strengen Abläufen und bündeln trotzdem wertvolle Ressourcen: GPUs, Modelle, Daten und Zugangsschlüssel zu Cloud-Diensten. Ähnlich wie zuletzt beim Patchday November 2026 gilt deshalb: Sobald eine Lücke im KEV-Katalog steht, ist sie keine theoretische Gefahr mehr. Wer GPUStack betreibt, sollte Version, Erreichbarkeit und API-Schlüssel noch heute prüfen.
