al-ice.ai

Localhost Was Whoever Asked: GPUStack Loopback Admin Bypass Hits CISA KEV

AI Vulnerabilities & CVEs by al-ice.ai Editorial

CISA’s 9 November Known Exploited Vulnerabilities update put an AI-infrastructure flaw on a three-day clock: CVE-2026-102895, an improper-authentication bug in GPUStack — the open-source GPU cluster manager for AI model serving — now carries a federal remediation deadline of 12 November 2026. The defect is stark. Before version 2.2.0, get_current_user in gpustack/api/auth.py promoted any request whose source appeared to be loopback to the built-in administrator account whenever force_auth_localhost was false — which was the default. And “appeared to be loopback” turned out to be attacker-controlled two ways over: through a same-host reverse proxy, where every remote request arrives with TCP peer 127.0.0.1 in the canonical self-hosted shape (proxy_pass to 127.0.0.1), and through a forged X-GPUStack-Real-IP: 127.0.0.1 header. Either path yielded full unauthenticated administrative access over the network — user and model management, persistent admin API keys scoped [“*”] and valid from any source IP thereafter, worker and cloud-provider secret disclosure, and code execution on worker hosts via POST /v2/inference-backends/from-yaml. The advisory states the flaw has been observed exploited in the wild against a 2.1.1 deployment, with attacker-created custom backends running reverse shells. NVD rates it 9.8 CRITICAL.

The root cause is a design sentence

The advisory’s root-cause section is one line worth memorizing: trusting the network source of a request — socket peer or client-controllable header — as an authentication signal. The “localhost is trusted” assumption collapses the moment a reverse proxy sits on the same host, because the socket peer is then always loopback by construction; the reporter verified the proxy path end-to-end against upstream HEAD with no header or credential at all. The fix, shipped in 2.2.0 (fix commit 19 May, release June), removed the loopback auto-admin path and hardened client-IP and forwarding-header handling. Note the timeline this creates: the patch has existed for months, the advisory followed, NVD analyzed the record on 4 November — and exploitation plus KEV listing still arrived in November. That is the standard lifecycle of infrastructure CVEs now: fix available, advisory public, exploit observed, emergency deadline, with the long tail of unpatched self-hosted GPU fleets in between. The advisory’s workarounds — force_auth_localhost=true, stripping client-supplied X-GPUStack-Real-IP at the edge, keeping the API off untrusted networks — are defense for anyone who cannot upgrade today, not substitutes for 2.2.0.

A loopback month, and a KEV batch with three companions

This is the second loopback-trust failure on this site in two days: the Mendix Studio Pro MCP Server pair likewise treated loopback as a trust decision the network did not honor. The two belong to the same genus — localhost as an authentication factor — and both died the same way, at the boundary where a proxy or a peer address meets an authorization check. Defenders should read them as one audit task across every self-hosted AI component: anywhere “from localhost” implies “is admin,” assume the proxy topology already voids it. The KEV batch itself adds context: alongside GPUStack, CISA listed CVE-2026-116779 (SignalWire FreeSwitch code injection), CVE-2026-123158 (OpenBSD OpenSSH), and CVE-2026-123218 (IBM Aspera Faspex) — all added 9 November, all due 12 November, all carried here via the CISA catalog rather than independently verified. GPUStack is the one that sits directly on model-serving infrastructure, which is why it leads: the Kubeflow cross-tenant cache-key flaw earlier this month already showed AI orchestration layers failing at tenant boundaries, and the October PolyShell/Brotli KEV additions showed how fast exploited-in-the-wild status converts into federal deadlines. A GPU fleet manager with a 9.8 loopback bypass and confirmed reverse-shell exploitation fits that machinery exactly.

What to actually do

  1. Upgrade to GPUStack 2.2.0 or later before the 12 November KEV deadline — and treat any 2.1.x deployment reachable from untrusted networks as potentially already compromised, given confirmed in-the-wild exploitation with reverse shells.
  2. Hunt for attacker-created inference backends and rogue admin API keys: enumerate persistent keys (especially scope [“*”]) and custom backends that predate the upgrade, and rotate worker and cloud-provider secrets the API could reach.
  3. Audit every self-hosted AI component for loopback-as-admin: reverse-proxy topologies, X-Forwarded-For-style headers, and force-auth-localhost-type flags — the Mendix pair this week proves the pattern repeats.
  4. Put management APIs behind authenticated gateways: strip client-supplied real-IP headers at the edge and never expose cluster managers directly, even with force_auth_localhost enabled.

Our verification was read-only. We read GHSA-gj9m-f8ph-pmhr first-hand in full via the GitHub API (critical severity, CVE-2026-102895, CVSS 3.1 9.8, get_current_user loopback auto-admin with force_auth_localhost=false default, both bypass paths with the proxy_pass shape and X-GPUStack-Real-IP header, HEAD-verification note, full admin impact including scoped persistent keys and from-yaml code execution, in-the-wild exploitation against 2.1.1 with reverse-shell backends, 2.2.0 fix, and workarounds), the full NVD JSON (published 4 November 2026, Analyzed, matching description and references), the fix commit record (53f42a6a, “fix: remove localhost auto-admin bypass,” 19 May 2026) and v2.2.0 release record via API, the CISA 9 November KEV alert page first-hand (four additions), and the KEV catalog CSV for exact due dates (all four due 12 November 2026). The three non-GPUStack KEV siblings are carried via CISA only and stated as such. We ran no GPUStack instance, crafted no header, created no backend, and contacted no vendor. Brave Search was used for discovery only.

Sources: