GPUStack Improper Authentication Vulnerability

🚨SEVERITY: CRITICAL — CVSS 9.8Security Advisory

TL;DR 📌

  • GPUStack contains an improper authentication vulnerability which could allow unauthenticated administrative access, including user and model changes, persistent administrator API-key creation, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml.
  • Highest CVSS: 9.8 (Critical).
  • Listed in CISA KEV (2026-11-09) — this is being exploited in the wild.
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2026-102895.

What it is

CVE-2026-102895 is an authentication bypass in GPUStack, the open-source GPU cluster manager used for AI model serving and GPU instance provisioning. The flaw sits in get_current_user in gpustack/api/auth.py, which treats any request that appears to originate from the loopback address as the built-in administrator. This loopback trust is controlled by force_auth_localhost, which defaults to false.

The problem is in how the “is this really loopback” decision gets made. The IP-resolution logic, client_ip_getter, accepts a same-host reverse proxy peer or a client-supplied X-GPUStack-Real-IP header as authoritative. An attacker on the network can simply set that header to 127.0.0.1 and have their request treated as coming from the administrator’s own machine — no credentials required.

Once authenticated as admin this way, an attacker can create and modify users, alter models, mint persistent administrator API keys, read worker and cloud-provider secrets, and reach POST /v2/inference-backends/from-yaml, which allows code execution. This is full administrative control of the cluster manager over the network, unauthenticated.

The vulnerability is in CISA’s KEV catalogue (added 2026-11-09), and the NVD description states exploitation was observed in the wild against a 2.1.1 deployment.

What to do

  • Upgrade to GPUStack 2.2.0, where this is fixed, as a priority — this is listed in CISA KEV and exploitation against 2.1.1 has been observed.
  • If upgrading isn’t immediately possible, set force_auth_localhost to true so loopback-sourced admin trust can’t be triggered remotely, and check whether your deployment currently relies on the default (false).
  • Review any reverse proxy or load balancer in front of GPUStack: strip or ignore client-supplied X-GPUStack-Real-IP headers at the edge, and ensure the proxy does not present itself as the same host as the GPUStack process in a way client_ip_getter would trust.
  • After upgrading, audit for signs of prior compromise: unexpected user accounts, unfamiliar administrator API keys, changes to model or worker configuration, and any inference-backend definitions created via POST /v2/inference-backends/from-yaml that you didn’t create.
  • Rotate any worker and cloud-provider secrets stored in GPUStack, since the flaw allowed their disclosure.

For leadership 🧭

Executive summary. GPUStack’s cluster manager can be tricked into treating any remote request as coming from its built-in administrator simply by setting a header, handing an attacker full control of users, models, secrets and code execution with no login required. This is already in CISA’s KEV catalogue with confirmed exploitation against a 2.1.1 deployment, so it needs same-day attention, not scheduling into the next maintenance window.

Why it matters:

  • The flaw lets an attacker set the X-GPUStack-Real-IP header to 127.0.0.1 and be treated as the built-in administrator, with no credentials, password or token required.
  • Administrative access gained this way extends to creating persistent admin API keys, changing users and models, and reading worker and cloud-provider secrets stored by GPUStack.
  • POST /v2/inference-backends/from-yaml is reachable under this bypass, giving the attacker a path to code execution on the cluster manager itself.
  • Exploitation has already been observed in the wild against a 2.1.1 deployment, and the CVE is listed in CISA’s KEV catalogue (added 2026-11-09).

Now / Next / Later:

  • Now: If you cannot upgrade immediately, set force_auth_localhost to true and confirm whether any current deployment is still running on the vulnerable default of false.
  • Next: Upgrade all GPUStack instances to 2.2.0 in the next available change window, and configure any reverse proxy or load balancer in front of it to strip client-supplied X-GPUStack-Real-IP headers and avoid presenting as the same host GPUStack would trust.
  • Later: Build a standing check into deployment pipelines for GPUStack (and similar internal tooling) that verifies loopback-trust and proxy-header handling before go-live, and rotate worker and cloud-provider secrets plus audit for unfamiliar admin API keys, users or inference-backend definitions after any upgrade.

Source