GPUStack auth bypass added to CISA KEV after in-the-wild exploitation

CISA added an improper authentication flaw in GPUStack, an open-source GPU cluster manager for AI model serving and GPU instance provisioning, to its Known Exploited Vulnerabilities catalog on 9 November 2026. The due date for federal remediation under the directive cited in the entry is 12 November 2026. The vendor's description says exploitation was observed in the wild against a 2.1.1 deployment.

The NVD entry carries a CVSS 3.1 base score of 9.8 from the CNA, with a vector of network attack, low complexity, no privileges and no user interaction. The affected range is versions before 2.2.0. The vendor advisory, a pull request and a commit are listed as references, and 2.2.0 is the release that carries the fix.

What the bug actually is

The flaw sits in get_current_user in gpustack/api/auth.py. Before 2.2.0, that function treated any request coming from loopback as the built-in administrator, provided force_auth_localhost was false, which was the default.

The interesting part is how a remote request could look local. The client IP getter accepted a same-host reverse proxy peer, or a client-supplied X-GPUStack-Real-IP header with a loopback value. So an attacker who could reach the API through a proxy on the same host, or who could set that header and have it trusted, was treated as the admin.

What that buys, per the vendor: user and model changes, creation of a persistent administrator API key, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml. The last one is the part that turns an access-control bug into a foothold on the host.

Why this one matters more than the score suggests

A 9.8 on an open-source component is routine enough that it's easy to skim past. The deployment context is what makes this worth a second look. GPUStack sits in front of GPU capacity and model serving, and it holds credentials for cloud providers and worker nodes. An attacker who lands admin doesn't just read a dashboard. They get the keys to the compute, and they can mint an API key that survives a restart.

The persistence angle is the one we'd flag hardest. A created administrator API key doesn't disappear when the process restarts or when someone notices odd traffic. If a box was exposed and reachable, rotating the obvious secrets isn't enough on its own; the key list needs checking.

The header trust is also a familiar shape. Anything that decides "this request is local" from a header a client can set is one proxy misconfiguration away from being wrong. The default of not forcing auth on localhost is a convenience that assumes the loopback interface is only reachable by trusted processes, and that assumption fails as soon as a reverse proxy sits in the path.

HackZoneLabs assessment

In our view, the KEV listing and the vendor's note about exploitation against 2.1.1 are the two facts that should drive triage, not the score. A critical rating tells you the bug is bad in theory; a KEV entry with a three-day due date tells you someone is already using it. We would treat any GPUStack instance below 2.2.0 that has been reachable from outside the host as potentially compromised rather than merely unpatched, and we'd look at administrator API keys and inference backend definitions before looking at anything else. The vendor's own list of what the bypass reaches is a decent checklist for what to audit.

We'd also be cautious about the "same-host reverse proxy" condition. It narrows the exposure compared with a bug that any internet client can hit directly, but plenty of deployments put a proxy in front of an API as a matter of course. Whether a given instance was actually exploitable depends on its proxy layout and header handling, and the advisory doesn't spell that out per deployment.

What's still unknown

The advisory doesn't say how many deployments were hit, who was behind the observed exploitation, or what the attacker did after getting in. The KEV entry lists ransomware use as unknown. There's no public write-up of the incident we've seen referenced in the retained material, so the "observed in the wild" line is a vendor statement without published detail behind it.

The entry also doesn't say whether the X-GPUStack-Real-IP header path alone was enough on a directly exposed instance, or whether the proxy peer condition was required. That distinction matters for anyone deciding how urgent their own case is.

What to check first

Upgrade to 2.2.0 or later. Then, on any instance that ran an earlier version while reachable, review administrator API keys for ones nobody created, check inference backend definitions for anything unexpected, and rotate worker and cloud-provider credentials that the service held. If the instance sat behind a reverse proxy, confirm whether that proxy passed client-supplied real-IP headers through to the application.

CVE references

CVE-2026-102895