Die US-Cybersicherheitsbehörde CISA hat am 9. November 2026 die GPUStack-Lücke CVE-2026-102895 in ihren Katalog aktiv ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen. In Versionen vor 2.2.0 verschafft sie Angreifern ohne Anmeldung Administratorrechte im Cluster-Manager und darüber die Möglichkeit, Code auf den angeschlossenen GPU-Servern auszuführen. Die Lücke selbst ist älter: Die korrigierte Version 2.2.0 erschien am 18. Juni 2026, die Sicherheitswarnung der Entwickler am 31. Juli, der CVE-Eintrag am 4. November.

GPUStack ist ein Open-Source-Projekt, das GPU-Cluster verwaltet, KI-Modelle etwa mit vLLM oder SGLang bereitstellt und bei Bedarf GPU-Instanzen vergibt. Die Entwickler bewerten die Lücke nach CVSS 3.1 mit 9,8 von 10 Punkten („kritisch“); denselben Wert enthält der CVE-Eintrag, den GitHub als Vergabestelle (CNA) aus dem Advisory erzeugt hat. Laut Advisory wurde die Lücke bereits gegen eine Installation mit Version 2.1.1 ausgenutzt: Die Angreifer legten eigene Inferenz-Backends an, die Reverse Shells starteten – Verbindungen, über die sich ein Server fernsteuern lässt. Gemeldet hat diese Angriffe laut Advisory Javier Sixto (ulex.fr). Wann sie stattfanden und ob weitere Installationen betroffen sind, geht aus den Primärquellen nicht hervor.

Der Kern: Wer von localhost kam, war Administrator

Die Ursache steckt in wenigen Zeilen der Funktion get_current_user in gpustack/api/auth.py. In Version 2.1.1 lauten sie:

if user is None and client_ip_getter(request=request) == "127.0.0.1":
    if not server_config.force_auth_localhost:
        user = await User.first_by_field(session, "is_admin", True)

Brachte eine Anfrage keine gültigen Zugangsdaten mit, kam aber scheinbar vom Server selbst, meldete GPUStack sie stillschweigend als ersten Administrator an. Abschalten ließ sich das mit der Option force_auth_localhost – die stand laut Dokumentation von Version 2.1 aber standardmäßig auf False.

Die Annahme „localhost ist vertrauenswürdig“, wie die Entwickler sie selbst nennen, hält einem sehr verbreiteten Aufbau nicht stand: GPUStack hinter einem Reverse Proxy wie nginx auf demselben Rechner, angebunden etwa mit proxy_pass http://127.0.0.1:<Port>. Ein Reverse Proxy reicht die Verbindung des Besuchers nicht einfach durch. Er nimmt die Anfrage aus dem Netz an und baut selbst eine neue Verbindung zur Anwendung auf – und die beginnt auf demselben Rechner nun einmal bei 127.0.0.1. Für GPUStack sieht damit jede Anfrage aus dem Internet aus wie eine lokale, und jeder anonyme Besucher wird zum Administrator. Header oder Zugangsdaten braucht es dafür nicht. Die echte Adresse des Besuchers steht bei so einem Aufbau allenfalls in einem Header, den der Proxy hinzufügt – und Headern darf eine Anwendung nur trauen, wenn ausschließlich ein vertrauenswürdiger Proxy sie setzen kann.

Genau daran scheitert der zweite Angriffsweg. Je nach Betriebsart übernimmt GPUStack die Absenderadresse laut Quellcode nicht aus der TCP-Verbindung, sondern aus dem Header X-GPUStack-Real-IP. Laut Advisory kann ein gefälschter Header mit dem Wert 127.0.0.1 genügen, damit eine Anfrage als lokal gilt. Die Entwickler fassen die Ursache so zusammen: GPUStack habe die Netzwerkherkunft einer Anfrage – die Gegenstelle der Verbindung oder einen vom Client steuerbaren Header – als Anmeldemerkmal behandelt.

Vom Admin-Zugang zur Shell auf dem Worker

Mit den erschlichenen Rechten können Angreifer laut Advisory Benutzer, Modelle, Worker und Konfiguration auslesen und ändern, Zugangsdaten der Worker sowie Geheimnisse von Cloud- und Modellanbietern lesen und dauerhafte Admin-API-Schlüssel anlegen. Diese Schlüssel gelten für alle Bereiche und funktionieren danach von jeder IP-Adresse aus – also auch nach einem Update. Zusammen mit Admin-Funktionen wie dem Endpunkt POST /v2/inference-backends/from-yaml, über den sich eigene Inferenz-Backends anlegen lassen, führt das zur Codeausführung auf den Worker-Rechnern. Genau dieses Muster beschreibt das Advisory für den beobachteten Angriff.

Symbolbild: GPU-Baugruppe Nvidia HGX B200 mit acht großen Kühlkörpern auf einem Holztisch

Bild: Symbolbild – Achtfach-GPU-Baugruppe Nvidia HGX B200. Foto: Pokiiri, Lizenz CC BY-SA 4.0, via Wikimedia Commons

Fix seit Juni, weitere Lücken seitdem

Version 2.2.0 entfernt die automatische Admin-Anmeldung für localhost vollständig; der Commit „fix: remove localhost auto-admin bypass“ stammt vom 19. Mai 2026. Die Option --force-auth-localhost führt die Dokumentation seit 2.2 nur noch als veraltet und wirkungslos, weil lokale Aufrufer ohnehin authentifiziert werden. In den Release Notes von 2.2.0 taucht die Korrektur nicht als Sicherheitsfix auf.

Wer jetzt aktualisiert, sollte nicht bei 2.2.0 stehen bleiben. GPUStack hat seitdem weitere Advisories veröffentlicht: Eine SAML-Lücke, die ebenfalls die Anmeldung umgeht (CVE-2026-102894, CVSS 9,1), und eine fehlende Rechteprüfung im Kubernetes-API-Proxy (CVE-2026-103002, CVSS 8,8) sind erst in 2.2.2 behoben, acht weitere am 26. Oktober veröffentlichte Lücken erst in der aktuellen Version 2.3.0 vom 23. Oktober.

Für US-Bundesbehörden gilt nach der KEV-Aufnahme eine Frist bis zum 12. November 2026. Die CISA hat den Eintrag zudem mit „Forensic Triage“ markiert: Nach den Umsetzungsvorgaben ihrer Richtlinie BOD 26-04 müssen Behörden dann auch prüfen, ob Systeme bereits kompromittiert wurden. Ob die Lücke bei Ransomware-Angriffen eine Rolle spielt, führt der Katalog als unbekannt.

Was du jetzt tun solltest

Version prüfen. Bei der Docker-Installation aus der Dokumentation heißt der Container gpustack:

sudo docker exec gpustack gpustack version

Alles unter 2.2.0 ist für CVE-2026-102895 anfällig.

Aktualisieren. Laut Dokumentation sicherst du zuerst die Datenbank, aktualisierst dann den Server und erst danach die Worker. Bei Docker heißt das: neues Image holen, alten Container entfernen und mit denselben Parametern und Volumes neu starten:

sudo docker pull gpustack/gpustack:v2.3.0
sudo docker stop gpustack
sudo docker rm gpustack
sudo docker run -d --name gpustack ... gpustack/gpustack:v2.3.0

Falls das Update warten muss. Das Advisory nennt drei Sofortmaßnahmen. Erstens force_auth_localhost einschalten – in der Konfigurationsdatei als force_auth_localhost: true, per Startparameter --force-auth-localhost oder als Umgebungsvariable GPUSTACK_FORCE_AUTH_LOCALHOST=true. Zweitens den Header X-GPUStack-Real-IP am Proxy entfernen, damit kein Client ihn einschleusen kann. In nginx genügt dafür ein leerer Wert, denn leere Header gibt nginx nicht weiter:

proxy_set_header X-GPUStack-Real-IP "";

Drittens die API nur aus vertrauenswürdigen Netzen erreichbar machen, etwa über ein VPN oder eine vorgeschaltete Anmeldung. Bei einem Reverse Proxy auf demselben Rechner bleibt force_auth_localhost die entscheidende Maßnahme – das Entfernen des Headers allein schließt den ersten Angriffsweg nicht.

Nach Spuren suchen. Ein Update entfernt nichts, was Angreifer bereits angelegt haben. Prüfe deshalb API-Schlüssel, Benutzerkonten und Inferenz-Backends auf Einträge, die du nicht selbst angelegt hast, und lösche sie. Auf den Worker-Rechnern lohnt der Blick auf fremde Container, Prozesse und ausgehende Verbindungen. Hinweise liefert auch das Access-Log des Reverse Proxy, etwa Aufrufe des Endpunkts für eigene Backends (Pfad je nach System):

zgrep "inference-backends/from-yaml" /var/log/nginx/access.log*

Weil Angreifer Zugangsdaten der Worker sowie Geheimnisse von Cloud- und Modellanbietern lesen konnten, solltest du bei einem Verdacht alle in GPUStack hinterlegten Cloud-Zugänge, Tokens und API-Schlüssel bei den jeweiligen Anbietern erneuern.

Quellen

Bildnachweis