GPUStack CVE-2026-102895: CISA KEV Loopback Auth Bypass and Worker Code Execution

CISA added GPUStack CVE-2026-102895 to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026, with a federal remediation deadline of November 12. The flaw is an improper authentication bypass in GPUStack before 2.2.0: when the server thinks a request came from loopback, it logs the caller in as the built-in administrator without checking credentials. A typical nginx proxy_pass http://127.0.0.1:port layout, or a forged X-GPUStack-Real-IP: 127.0.0.1 header, is enough from the internet. If you run GPUStack to serve models to coding agents or CI jobs, upgrade to 2.2.0 or later, turn on force_auth_localhost=true until you patch, strip client-supplied forwarding headers at the edge, and audit API keys and custom inference backends.

GPUStack is an open-source GPU cluster manager for model serving and GPU provisioning. Teams use it beside tools like Xinference on rented GPU boxes, lab servers, and internal inference tiers that agents call through OpenAI-compatible APIs. The GitHub advisory GHSA-gj9m-f8ph-pmhr rates the issue Critical, CVSS 9.8, and states that exploitation was observed against v2.1.1 with attacker-created backends running reverse shells. Our earlier coverage of GPU hosts targeted by Hugging Face miners shows why inference control planes are already on attacker shopping lists; this bug turns that interest into unauthenticated admin on a common manager.

TL;DR

A separate critical flaw, GPUStack CVE-2026-102894 (unverified SAMLResponse at /auth/saml/callback), requires GPUStack 2.2.2+—2.2.0 alone does not close that path.

What CISA and the vendor document

CISA's catalog entry for CVE-2026-102895 (added 2026-11-09, due 2026-11-12) describes unauthenticated administrative access including user and model changes, persistent administrator API-key creation, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml. Required action is vendor mitigations with BOD 26-04 compliance and forensic triage. Ransomware use is listed unknown.

The GitHub advisory names the root cause plainly: trusting the network source of a request as an authentication signal. In gpustack/api/auth.py, get_current_user promotes loopback sources to the built-in administrator when force_auth_localhost is False, which is the default. client_ip_getter derives that source from the TCP peer or from forwarding headers.

Two independent paths reach admin:

1. Same-host reverse proxy. When GPUStack sits behind nginx (or similar) with proxy_pass http://127.0.0.1:<port>, every remote client appears as TCP peer 127.0.0.1. The loopback branch fires with no password and no header trickery. The advisory says this was verified end-to-end.
2. X-GPUStack-Real-IP spoofing. A client sends X-GPUStack-Real-IP: 127.0.0.1 and the getter treats the source as loopback.

Either path yields the same capabilities: enumerate and modify users, models, workers and configuration; mint persistent admin API keys with scope ["*"] usable from any IP afterward; read worker credentials and cloud-provider secrets; and reach admin-only routes such as POST /v2/inference-backends/from-yaml, which the vendor ties to code execution on worker hosts and to observed reverse shells.

Credit in the advisory goes to independent reporters Nikko Enggaliano, Wei Yunzhou, and Rui Yang and Haoyu Wang (Johns Hopkins University), with in-the-wild exploitation reported by Javier Sixto (ulex.fr).

Attack chain, step by step

This is the chain as the advisory describes it, not a reproduced exploit:

1. Reach the GPUStack API over the network (AV:N, no privileges, no user interaction).
2. Make the server believe the client is loopback — either by routing through a same-host reverse proxy so the socket peer is 127.0.0.1, or by supplying X-GPUStack-Real-IP: 127.0.0.1 where the getter accepts it.
3. Receive built-in administrator session or token behavior without authenticating, because force_auth_localhost defaults to false and the loopback auto-admin path is active.
4. Persist access by creating admin API keys with broad scope that work from attacker IPs later.
5. Read secrets stored for workers and cloud providers — the kinds of credentials CI and agents later use to pull weights or talk to object storage.
6. Install a malicious inference backend via YAML upload, pushing execution to worker nodes where model workloads run, which the vendor connects to observed reverse shells on v2.1.1.

Step six is what elevates this from "another leaked dashboard password" to infrastructure takeover. Workers are often less patched than the API host and share GPU machines with other tenants in research settings.

Timeline

Who is affected

In scope: any GPUStack deployment below 2.2.0, particularly:

• Self-hosted stacks on VPS or lab metal with nginx or another reverse proxy on the same machine
• Clusters where the API port is reachable from a office VPN, flat lab network, or the public internet without an additional auth layer
• Shared research GPUs where multiple projects point agents at one OpenAI-compatible base URL

Out of scope for this specific bug: patched 2.2.0+ builds, and architectures where GPUStack is not reachable except through an authenticated gateway that does not present loopback peers to the app.

The advisory is explicit that the "localhost is trusted" assumption fails once a reverse proxy terminates TLS and forwards to 127.0.0.1. That is the normal production shape, which makes the default configuration dangerous.

What to do now

Upgrade:

pip show gpustack
pip install --upgrade 'gpustack>=2.2.0'

Confirm the running service version matches the package after restart. If you deploy with containers or systemd, rebuild or roll the unit so the new code is live, not only installed on disk.

Until you patch:

• Set force_auth_localhost=true so loopback requests still require real credentials.
• At the reverse proxy, drop client-supplied X-GPUStack-Real-IP unless you operate a trusted gateway that sets it yourself.
• Restrict the admin API to VPN or SSO-protected paths; do not rely on "obscure port" alone.

After suspected compromise:

• Revoke and reissue all GPUStack API keys, especially any with admin or star scope.
• Delete unknown inference backends and compare worker processes to a known-good snapshot.
• Rotate cloud and worker secrets the control plane stores (object storage keys, provider tokens, registry credentials).
• Review model paths and user accounts created in the incident window.

For a broader rotation checklist when a vendor control plane leaks secrets, see your first 24 hours after a vendor breach.

What this means if you run AI coding agents

Coding agents rarely install GPUStack themselves, but they consume it constantly: a .env or MCP config often sets OPENAI_BASE_URL to an internal GPUStack endpoint and drops an API key beside it. Compromise of the control plane is compromise of every agent and script that trusted that endpoint.

Concrete checks:

• Search agent configs for GPUStack hostnames, custom ports, and X-GPUStack-Real-IP allow rules in nginx snippets checked into repos.
• Compare model names agents call against what you actually deployed; a malicious backend can impersonate a familiar model ID.
• Treat inference keys like production secrets. If admin was reachable, assume keys in the GPUStack database and in developer laptops need rotation — the same pattern as LLMjacking against exposed LiteLLM proxies and Symantec's Skynet-mode write-up.
• Patch sibling stacks. If you run vLLM or other self-hosted engines on the same hosts, assume lateral movement from a worker shell is possible.

Agents will happily keep calling a poisoned endpoint until credentials fail. Fixing GPUStack does not rewind tool calls that already exfiltrated data through a trojan model route.

Reverse-proxy shapes that trip the bug

The advisory's canonical failure mode is not exotic. A single-machine install might run GPUStack on port 8080 and nginx on 443, with a block resembling:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
}

From GPUStack's socket view, every HTTPS client is peer 127.0.0.1. That is correct HTTP forwarding and incorrect authentication input. Moving TLS termination to a different host than the API process breaks the peer loopback pattern, but many small teams colocate them to save GPU rental cost.

If you terminate TLS at a cloud load balancer that forwards to GPUStack with PROXY protocol or custom headers, audit whether any header GPUStack reads can still assert loopback. The 2.2.0 fix is meant to stop treating those signals as proof of identity; until you upgrade, assume any header named like a "real client IP" is attacker-controlled unless your edge strips inbound values.

Signs to audit after KEV listing

None of these prove compromise alone, but together they justify rotation:

• API keys with admin scope created when no human admin was logged in
• Inference backend YAML entries you do not recognize, especially names mimicking legitimate runtimes
• Worker registration churn or workers reporting images you did not publish
• Model routes returning different tokenizer metadata than your known weights
• nginx access logs showing POST /v2/inference-backends/from-yaml or admin user routes without matching SSO sessions

GPUStack's advisory ties observed attacks to custom backends running reverse shells. On shared GPU hosts, also look for unexpected listening ports from worker processes and outbound connections from the service account running workers.

How this compares to other inference CVEs

This is not a model deserialization bug like some vLLM advisory chains we covered in October. Attackers never needed a malicious checkpoint; they needed reachable admin on the control plane. That makes the blast radius closer to GitLab's KEV-listed CI RCE — steal the keys the automation already owns — than to a single bad Python file in a Hugging Face repo. Defense therefore starts with network placement and proxy layout, not only trust_remote_code hygiene.

What Beam can and cannot do here

Beam watches coding agents on developer machines — tool calls, credential patterns, destructive commands — not GPUStack's HTTP API or nginx configs. It does not patch inference servers or detect loopback auth bypass.

Where it still helps: if an attacker pivots from GPUStack into a developer workspace (stolen API keys in shell history, agent-driven curl to a malicious backend, or MCP configs pointed at a hostile base URL), Beam's heuristic skill and MCP config scanning and hook-based deny on Claude Code and Codex PreToolUse can surface risky follow-on actions before they persist locally. That is a backstop, not a substitute for upgrading GPUStack. Limits: heuristic scans are not malware analysis; enforce modes need cached policy and remain fail-open when policy is missing.

See how Beam watches agent activity and November 2026 attacks timeline for related incidents this month.

Related reading

• Kubeflow Pipelines CVE-2026-77596 shared upload authorization gap

• Hugging Face trust_remote_code campaign targeting GPU hosts

• GitLab CVE-2026-97229 CISA KEV pattern

• LLMjacking and stolen agent API keys

• Wiz on AI-driven cloud attack chains

• Railway breach and environment variable rotation

Frequently asked questions

What is GPUStack CVE-2026-102895?

It is a critical authentication bypass in GPUStack before 2.2.0. The server promotes requests whose source is treated as loopback to the built-in administrator when force_auth_localhost is false, the default. A same-host reverse proxy or a forged X-GPUStack-Real-IP header can trigger that path from the network.

Which GPUStack versions are affected?

Every release before 2.2.0 is affected, per GitHub advisory GHSA-gj9m-f8ph-pmhr. Version 2.2.0 removes the loopback auto-admin branch and hardens client-IP handling. The vendor reports exploitation against 2.1.1.

Is CVE-2026-102895 in CISA KEV?

Yes. CISA added it on November 9, 2026, with a due date of November 12, 2026, forensic triage required under BOD 26-04, and no known ransomware tie listed.

What can an attacker do after the bypass?

Full administrative API access: change users, models, workers and configuration; create persistent admin API keys with scope star valid from any IP; read worker and cloud-provider secrets; and use POST /v2/inference-backends/from-yaml to run code on worker hosts, which the advisory links to in-the-wild reverse shells.

How do I check whether my deployment was hit?

Review admin API audit logs if you have them, enumerate API keys and users created after your last known-good backup, list custom inference backends especially those added via YAML, and compare worker images and processes to your baselines. Rotate every secret the control plane and workers could reach if anything looks new or unexplained.

Does this affect cloud-hosted inference only?

The risky pattern is self-hosted GPUStack, often behind nginx or another reverse proxy on the same host. Any internet-exposed control plane without edge authentication is in scope. Workers that register to that server inherit whatever backends an attacker installs.

Advisory text, CISA KEV fields, and version numbers reflect public sources as of November 9, 2026. Confirm fixed versions on your install method before declaring a host clean.