GPUStack Patches Critical Loopback Authentication Bypass (CVE-2026-102895), Already Exploited in the Wild

What happened

A GitHub Security Advisory (GHSA-gj9m-f8ph-pmhr) discloses an authentication bypass in GPUStack, an open-source GPU cluster manager for running AI models, affecting all versions before 2.2.0. According to the advisory, GPUStack's get_current_user function in gpustack/api/auth.py automatically promotes any request to the built-in administrator account if the request's source is considered "loopback" (127.0.0.1) — a behavior that is the default unless force_auth_localhost is explicitly enabled.

The advisory describes two ways an unauthenticated remote attacker can trigger this loopback condition without credentials: (1) in the common self-hosted deployment pattern where a reverse proxy on the same host forwards to GPUStack via proxy_pass http://127.0.0.1:<port>, every proxied request naturally arrives with a TCP peer of 127.0.0.1; and (2) a forged X-GPUStack-Real-IP: 127.0.0.1 header can cause the client IP resolution logic to treat an external request as loopback. The advisory states this has already been observed exploited in the wild against a v2.1.1 deployment, where an attacker created custom inference backends to run reverse shells.

Why it matters

Per the advisory, successful exploitation grants full, unauthenticated administrative access over the network: enumerating and modifying users, models, workers, and configuration; minting persistent admin API keys scoped to everything (["*"]) and valid from any source IP afterward; and reading worker credentials and cloud/provider secrets. The advisory also notes that admin-only functionality, such as creating inference backends from YAML, can be chained to achieve code execution on worker hosts. Given the reported CVSS score of 9.8, active in-the-wild exploitation, and a public PoC, any GPUStack deployment reachable from an untrusted network — including the very common same-host reverse-proxy configuration — should be treated as at immediate risk.

What defenders should do now

• Upgrade immediately to GPUStack 2.2.0 or later, where the advisory states the loopback auto-admin path has been removed and client-IP/forwarding-header handling hardened.
• If upgrading isn't immediately possible, set force_auth_localhost=true per the advisory's documented workaround to require authentication even on loopback-sourced requests.
• Strip any client-supplied X-GPUStack-Real-IP header at the network edge/gateway before it reaches GPUStack, and ensure your reverse proxy configuration cannot cause external traffic to be mistaken for loopback traffic.
• Do not expose the GPUStack API to untrusted networks — restrict access behind a VPN or an authenticating edge gateway.
• Hunt for signs of prior compromise: review existing admin API keys for ones you don't recognize (especially any scoped ["*"]), audit recently created inference backends/workers for unexpected configurations, and check worker hosts for unauthorized processes or reverse-shell activity consistent with the in-the-wild activity described in the advisory.

Developing intel

This is a same-day disclosure with confirmed in-the-wild exploitation reported against at least one deployment; further details on exploitation scope or additional indicators may emerge. This post reflects the information published in the GitHub Security Advisory as of now — see the original advisory for full technical details and updates: GHSA-gj9m-f8ph-pmhr.