If you self-host LLMs with GPUStack, stop what you’re doing. CVE-2026-102895 — a CVSS 9.8 authentication bypass — is being actively exploited in the wild right now. Attackers need zero credentials to gain full admin access to your AI server. CISA added it to the Known Exploited Vulnerabilities catalog on November 9 with a November 12 remediation deadline. The fix is one command. Run it.
What GPUStack Is #
GPUStack is an open-source GPU cluster manager (Apache 2.0) that pools multiple GPU servers into a unified cluster for LLM inference. It manages vLLM, SGLang, and TensorRT-LLM backends, handles load balancing, provides RBAC, and exposes a unified API — essentially Ollama for teams. If you’re self-hosting Llama, Mistral, or Qwen at any scale beyond a single machine, there’s a good chance you’re running GPUStack.
The Flaw: Trusting Loopback in 2026 #
The vulnerability lives in gpustack/api/auth.py, in the get_current_user function. By default, force_auth_localhost is false, and the function promotes any request arriving from 127.0.0.1 to the built-in administrator — no token, no password, no checks.
There are two ways attackers exploit this. The first is structural: if GPUStack sits behind a reverse proxy on the same host (Nginx, Traefik, Caddy — the standard setup), every remote request arrives at GPUStack with TCP peer 127.0.0.1. Everyone on the internet becomes admin. The second vector is worse: an attacker can send the HTTP header X-GPUStack-Real-IP: 127.0.0.1 directly to GPUStack’s API port and bypass auth entirely, no proxy required.
Trusting network topology over credentials in 2026 is an inexcusable design decision. The official advisory confirms the fix required a full rewrite of the loopback trust logic. The default should have been force_auth_localhost=true from day one.
What the Attack Looks Like #
Exploitation of a live v2.1.1 deployment has been confirmed. The full RCE chain is clean and fast:
- Forge the
X-GPUStack-Real-IP: 127.0.0.1header on any request to the API - Gain full administrator access — enumerate users, models, workers, and cloud credentials
- POST a malicious backend to
/v2/inference-backends/from-yamlto execute arbitrary commands on the host - Create persistent admin API keys to maintain access after the session ends
- Exfiltrate cloud provider credentials stored in worker configuration
The end result: reverse shell on your GPU server, persistent backdoor, and your AWS/GCP/Azure credentials in attacker hands. A public PoC exists. This is not theoretical.
Patch It Now #
GPUStack 2.2.0 fixed the core authentication logic. Use 2.2.2, which includes additional hardening on top.
gpustack version
pip install --upgrade "gpustack>=2.2.2"
For Docker deployments:
docker pull gpustack/gpustack:v2.2.2
If You Can’t Patch Today #
Three mitigations reduce exposure while you plan the upgrade:
- Set
force_auth_localhost=truein your GPUStack configuration — this disables the loopback auto-admin behavior - Strip the
X-GPUStack-Real-IPheader at your reverse proxy before it reaches GPUStack (Nginx:proxy_set_header X-GPUStack-Real-IP "";) - Firewall the GPUStack API port — it must not be reachable from the public internet without VPN or edge authentication
These mitigations reduce the attack surface but do not eliminate it. Upgrade.
Post-Compromise Checklist #
If you ran a vulnerable version with the API accessible, treat the system as compromised until proven otherwise:
- Audit all API keys — revoke any you did not create
- Review all inference backends for unexpected or malicious entries
- Rotate every cloud provider credential stored in GPUStack
- Review worker node configurations for unauthorized changes
- Check system logs for POST requests to
/v2/inference-backends/from-yaml
The Bigger Picture #
CVE-2026-102895 landed in the same CISA KEV batch as OpenSSH SSHole (CVE-2026-123158). It is the first AI inference tool to reach the KEV catalog. That is not a coincidence — attackers are actively targeting AI infrastructure for GPU compute, model access, and the cloud credentials that live alongside inference workloads. If you manage self-hosted AI infrastructure, you are now a priority target. Treat your AI server with the same security rigor you’d apply to a database server.