# GPUStack CVE-2026-102895: Auth Bypass Exploited — Patch Now

> Source: <https://byteiota.com/gpustack-cve-2026-102895-auth-bypass-exploited-patch-now/>
> Published: 2026-11-10 13:08:21+00:00

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](https://securityonline.info/gpustack-authentication-bypass-cve-2026-102895-exploited/). Attackers need zero credentials to gain full admin access to your AI server. CISA added it to the [Known Exploited Vulnerabilities catalog](https://www.esecurityplanet.com/vulnerabilities/news-cisa-kev-gpustack-freeswitch-openssh-ibm-november-2026/) 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](https://advisories.gitlab.com/pypi/gpustack/CVE-2026-102895/) 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](https://blog.ostorlab.co/gpustack-auth-bypass-rce-cve-2026-102895.html) is clean and fast:

1. Forge the `X-GPUStack-Real-IP: 127.0.0.1` header on any request to the API
2. Gain full administrator access — enumerate users, models, workers, and cloud credentials
3. POST a malicious backend to `/v2/inference-backends/from-yaml` to execute arbitrary commands on the host
4. Create persistent admin API keys to maintain access after the session ends
5. 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.

```
# Check current version
gpustack version
# or: pip show gpustack | grep Version

# Upgrade
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:

1. Set `force_auth_localhost=true` in your GPUStack configuration — this disables the loopback auto-admin behavior
2. Strip the `X-GPUStack-Real-IP` header at your reverse proxy before it reaches GPUStack (Nginx:`proxy_set_header X-GPUStack-Real-IP "";` )
3. 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.