GPUStack Auth Bypass CVE-2026-102895 (CVSS 9.8) Exploited and Added to CISA KEV — Proxied 'Localhost' Requests Get Admin, Then Reverse-Shell Backends Run on GPU Workers

Critical · 2026-11-10 · By H.A

CISA has added GPUStack's loopback authentication bypass to KEV after attackers used it to mint admin API keys and run reverse-shell inference backends on GPU workers; upgrade to 2.2.2 and audit keys and backends.

Overview

CISA added CVE-2026-102895, an authentication bypass in the open-source GPU cluster manager GPUStack, to its Known Exploited Vulnerabilities (KEV) catalog on 9 November 2026. GPUStack is used to schedule and serve large language models and other AI workloads across pools of GPU workers. The flaw is rated CVSS 9.8.

The project's own advisory says the bug "has been observed exploited in the wild against a v2.1.1 deployment". In that intrusion the attackers created custom inference backends that started reverse shells on worker hosts. The fix shipped in GPUStack 2.2.0 in June 2026. The CVE ID and the exploitation note were only published in early November, so many operators may not have realised that an ordinary feature upgrade was also a security fix.

The Vulnerability

The bug is in how GPUStack decides who is calling its API. In version 2.1.1 and earlier, if a request carries no valid credentials but appears to come from 127.0.0.1, the server loads the first built-in administrator account and treats the request as that admin. It does not check the method, path or caller.

That shortcut becomes remotely reachable in two common setups:

• Same-host reverse proxy. When nginx or another proxy on the same machine forwards traffic with something like proxy_pass http://127.0.0.1:<port>, every remote request reaches GPUStack from a loopback address.
• Embedded gateway mode. Here GPUStack takes the client address from the X-GPUStack-Real-IP header. An attacker can set that header to 127.0.0.1 without any proxy in the path.

In both cases force_auth_localhost must be false or unset, which was the default before 2.2.0.

Admin access leads straight to code execution. An admin can call POST /v2/inference-backends/from-yaml to register a new backend definition, and that backend then runs on GPU worker nodes. An admin also has access to the worker and cloud-provider credentials stored in GPUStack.

A related flaw, CVE-2026-102894 (CVSS 9.1, SAML login), is fixed in 2.2.2. Upgrading to 2.2.2 or later closes both.

Timeline

• 19 May 2026: The fix commit lands, removing the loopback admin promotion.
• 18 June 2026: GPUStack 2.2.0 is released.
• 31 July 2026: The project publishes advisory GHSA-gj9m-f8ph-pmhr.
• 4 November 2026: CVE-2026-102895 is published, along with the in-the-wild exploitation report.
• 9 November 2026: CISA adds the CVE to KEV.

Tradecraft

The advisory describes this attack chain:

1. Send an unauthenticated API request that arrives at GPUStack from a loopback address, either through the proxy or with a spoofed header.
2. Act as the built-in administrator and create a new API key with the * scope. This key keeps working from any address, even after the proxy is fixed.
3. Register a malicious inference backend through the YAML import endpoint.
4. Let the scheduler start that backend on GPU workers, where it opens a reverse shell.

GPU clusters are attractive targets. Their hardware can be resold for cryptomining or LLMjacking, they often hold model weights and training data, and the credentials they store usually reach cloud accounts. Public proof-of-concept code is circulating, so expect broad automated scanning.

Indicators of Compromise

The project and CISA have not published network IOCs. These artefacts on a GPUStack deployment should be investigated:

• Admin API keys with the * scope that no one on your team created
• Inference backends created through from-yaml that are not in your change records
• Shell processes such as sh, bash or nc started by inference backend processes on workers
• Outbound connections from workers to unfamiliar hosts on non-standard ports

Detection

• Search GPUStack and proxy logs for successful (2xx) admin API calls that carry no Authorization header, especially to /v2/api-keys, /v2/users and /v2/inference-backends/from-yaml.
• Alert on any inbound request that contains an X-GPUStack-Real-IP header. Legitimate clients do not need to send it.
• Check the version on every node:

pip show gpustack | grep -i ^version
# or, for containers
docker inspect --format '{{.Config.Image}}' $(docker ps -q --filter name=gpustack)

• On workers, review the process tree under the backend runtime for interactive shells and unexpected outbound sockets:

ps -eo pid,ppid,user,cmd --forest | grep -B2 -A2 -E 'sh -i|/dev/tcp|nc '
ss -tnp state established

Recommended Actions

1. Upgrade to GPUStack 2.2.2 or later. That covers both CVE-2026-102895 and CVE-2026-102894.
2. If you cannot upgrade right away, set force_auth_localhost=true, strip client-supplied X-GPUStack-Real-IP headers at the proxy, and keep the API off the internet behind a VPN or allow-list.
3. Assume upgrading did not remove attacker access. Audit admin users and API keys, revoke anything unknown, and compare the inference backend list with your records.
4. Rotate the worker tokens and cloud-provider secrets stored in GPUStack. Then check the linked cloud accounts for unfamiliar instances, keys or storage buckets.
5. Rebuild any worker that ran an unauthorised backend instead of trying to clean it.

Analyst Assessment

CVE-2026-102895 is a familiar mistake on new infrastructure: the server trusts "localhost" in a deployment where localhost is really a reverse proxy. The patch has been out since June, but the late CVE and the KEV listing are what will make most teams notice it. AI serving stacks are often deployed fast by ML teams rather than platform security teams, and they sit next to expensive GPUs and powerful cloud credentials. We expect exploitation to keep rising now that a public PoC exists. Organisations should treat any internet-reachable GPUStack below 2.2.0 as possibly compromised until an audit shows otherwise.