⌁AI·CYBER·BRIEF▌
Vulnerabilities7 min read

GPUStack login bypass is being exploited to take over AI GPU clusters — CISA sets Nov. 12 deadline

A flaw in open-source GPUStack lets anyone become admin and run code on GPU workers. It is exploited in the wild and now in CISA's KEV catalog. Upgrade to 2.2.2+.

GPUStack, an open-source tool that teams use to run AI models across a cluster of GPU servers, had a login check that could be skipped entirely, handing an outsider full administrator rights. The project says the flaw (CVE-2026-102895) has been exploited in the wild, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog on November 9, 2026, with a November 12 deadline for federal agencies. If you run GPUStack, upgrade to version 2.2.2 or later now and check for admin accounts, API keys and inference backends you did not create.

What happened, in plain English

GPUStack is a "control panel" for AI hardware. You install a central server, connect GPU machines to it as "workers", and then use its web interface or API (application programming interface — the address programs use to talk to it) to download models, start them and hand out API keys to the apps that use them.

Older versions had a shortcut built in: if a request seemed to come from the server itself — the "localhost" or "loopback" address, 127.0.0.1 — GPUStack treated it as the built-in administrator, no password needed. That setting was on by default.

The problem is that "where did this come from?" is easy to get wrong. If you put GPUStack behind a reverse proxy (a front-door web server such as Nginx) running on the same machine, every visitor from the internet arrives through that proxy — and so appears to come from the machine itself. On top of that, GPUStack trusted a request header in which the client could simply claim to be local.

Think of an office building where the guard waves through anyone who says they came from inside — and the main entrance is a corridor that starts inside the building.

Once in as admin, an attacker can read stored credentials, create their own permanent API keys and, by registering a custom "inference backend" (the software that actually runs a model), run commands on the GPU servers. According to the project's advisory, that is exactly what happened on at least one real deployment.

Are you affected? What to do now

Who is affected

  • Anyone running self-hosted GPUStack older than 2.2.0 is exposed to CVE-2026-102895 (the login bypass). The exploited system ran v2.1.1.
  • A second critical flaw, CVE-2026-102894, affects versions 0.7.1 up to (but not including) 2.2.2: the single sign-on (SAML) login endpoint accepted login messages without checking their signature. The project says no configuration is needed for this one — the endpoint answers even if SAML is not set up. No exploitation of this second bug has been reported.
  • If you do not use GPUStack, you have nothing to do for this story. It is not a hosted cloud service; it is software you install yourself (via pip or Docker).

How to check

  • Find GPUStack installs: look for the gpustack Python package (pip show gpustack) or gpustack/gpustack container images, and note the version or image tag.
  • Check whether the server or its API is reachable from the internet or from broad internal networks, and whether a reverse proxy runs on the same host.

What to do, in order

  • Upgrade to 2.2.2 or later. 2.2.0 fixes the loopback bypass; 2.2.2 also fixes the SAML flaw. The project describes 2.2.2 as a security release and advises upgrading immediately.
  • If you cannot upgrade today, the advisory's workarounds are: set force_auth_localhost=true so local requests must also log in; make sure your proxy cannot make outside traffic look local; strip any X-GPUStack-Real-IP header sent by clients at the edge; block outside access to /auth/saml/callback; and keep the API off untrusted networks (VPN or authenticating gateway in front).
  • Assume compromise if an old version was exposed. Review users, admin API keys, workers and inference-backend definitions for anything you did not create; delete unknown entries.
  • Rotate secrets GPUStack stores or can see: worker credentials, model-provider API keys, cloud and registry tokens, and all GPUStack API keys.
  • Look at the GPU worker hosts, not just the server. The reported attack ran reverse shells (connections from the victim back to the attacker) through custom backends, so check for unexpected processes and outbound connections from workers.
  • In proxy logs, look for requests arriving with an X-GPUStack-Real-IP header and for admin actions (such as creating backends from YAML) you cannot account for. No official indicators of compromise (IP addresses, file hashes) have been published.

The expert view

Root cause. This is a textbook case of using network location as identity. get_current_user in gpustack/api/auth.py granted the built-in admin to any request whose source resolved to loopback, and the source came from a client-IP helper that honored a client-controlled header. Two independent paths reach the same outcome: a same-host reverse proxy (where the socket peer is always 127.0.0.1, so no forgery is needed at all) and header spoofing. The weaknesses listed are CWE-287 (improper authentication), CWE-290 (authentication bypass by spoofing) and CWE-346 (origin validation error).

Why it matters more than a typical web-app bypass. An AI cluster manager is a credential hub and a code-execution platform by design. Admin can define how inference backends are launched, which in practice means deciding what runs on GPU hosts. So the chain is short: network reachability → admin → backend definition → commands on workers. Those workers often sit next to model weights, datasets, object-storage keys and cloud credentials, and GPUs are attractive for cryptomining and LLMjacking (reselling stolen AI compute).

Severity in context. The project rates CVE-2026-102895 at CVSS 3.1 9.8 (network, no privileges, no user interaction). That score is fair for internet-exposed or proxied deployments. A server reachable only from a locked-down admin network is lower practical risk, but "internal only" is weak comfort against an attacker already inside. The SAML flaw, CVE-2026-102894, is rated 9.1; it lets an attacker name an existing admin and receive that admin's session, and captured responses could be replayed because message IDs were never tracked.

The timeline is the lesson. The fix shipped in v2.2.0 in June 2026; the GitHub advisory was published on July 31 without a CVE; the CVE and the KEV listing followed in November. Teams that track only CVE feeds would have seen nothing for months, while anyone following the project's advisories could have patched in the summer. For AI infrastructure — young projects, fast release cadence, many self-hosted installs — subscribe to the project's own GitHub security advisories, not just NVD.

Broader pattern. This sits alongside a run of authentication gaps in AI serving and agent tooling this autumn, including NVIDIA's NeMo Agent Toolkit, OpenHands sandboxes and AgentScope. The common thread: tools built for a trusted lab network, then deployed behind a proxy or onto the internet.

What is still unknown. The advisory confirms exploitation against one v2.1.1 deployment, reported by Javier Sixto (ulex.fr). It does not say how many systems were hit, who the attackers are, or what they did after gaining a shell. No one has attributed the activity to a specific group, and CISA's catalog does not mark it as known ransomware use. The original bug was reported independently by Nikko Enggaliano, Wei Yunzhou, and Rui Yang and Haoyu Wang (Johns Hopkins University); the SAML flaw by Austin Chu, Sohee Kim and Corban Villa (UC Berkeley).

Official sources

Get the daily brief

AI + security signal by email: headlines, a two-line summary, a link. No noise, no spam.

How often