GPUStack CVE-2026-102895 Auth Bypass Added to CISA KEV
Security

GPUStack CVE-2026-102895 Auth Bypass Added to CISA KEV

GPUStack CVE-2026-102895 gives unauthenticated attackers admin access and is exploited. Upgrade to 2.2.2 and hunt for rogue API keys and backends.

gpustackcisa kevauthentication bypassai infrastructure

GPUStack CVE-2026-102895 is an authentication bypass that hands unauthenticated attackers full administrator access to GPUStack, the open-source GPU cluster manager used to serve AI models. CISA added it to the Known Exploited Vulnerabilities catalog on November 9, 2026, with a remediation due date of November 12. The flaw is rated CVSS 9.8, exploitation was observed against a 2.1.1 deployment, and the fix is in version 2.2.0. Upgrade to 2.2.2, which also closes a second critical login flaw, then check for API keys and backends you did not create.

What happened

GPUStack decides who is calling its API partly by looking at where the request comes from. Before version 2.2.0, the get_current_user function in gpustack/api/auth.py treated any request that appeared to come from the loopback address as the built-in administrator. That behavior was controlled by a setting called force_auth_localhost, and its default was false, so the shortcut was on unless an operator turned it off.

The project's GitHub advisory (GHSA-gj9m-f8ph-pmhr) describes two ways a remote request could be made to look local without any credentials:

  • Same-host reverse proxy. When GPUStack sits behind a reverse proxy on the same machine that forwards traffic to 127.0.0.1, every remote request arrives with a loopback TCP peer. The advisory calls this the canonical self-hosted setup, and in it the auto-admin branch fires for everyone.
  • A client-supplied header. GPUStack accepted an X-GPUStack-Real-IP header from clients. A forged loopback value in that header could make the request count as local.

Either path gives full administrative control over the network. The advisory notes that this includes reading and changing users, models, workers and configuration, minting persistent admin API keys with scope ["*"] that keep working from any source address, and reading worker credentials and cloud provider secrets. Admin-only features such as POST /v2/inference-backends/from-yaml then allow code execution on worker hosts.

Exploitation in the wild was reported by Javier Sixto of ulex.fr. According to the advisory, attackers created custom inference backends that ran reverse shells on a 2.1.1 deployment. The CVE record was published on November 4, 2026, and CISA's KEV entry followed on November 9.

Who is affected

Every GPUStack installation older than 2.2.0 is affected by CVE-2026-102895. Risk is highest for deployments that:

  • run behind nginx, Caddy, Traefik or another reverse proxy on the same host (the advisory's own example of the vulnerable shape),
  • expose the GPUStack API or web console to the internet or to a broad internal network,
  • store cloud provider credentials in GPUStack for GPU instance provisioning, because those secrets are readable once an attacker is admin.

The KEV entry flags the issue as affecting an open-source component, marks known ransomware use as "Unknown" and sets the forensic triage flag to "Yes". Under BOD 26-04 that means federal agencies must look for compromise, not only patch. Private organizations should read that flag the same way.

GPUStack published a second critical advisory, GHSA-62m9-f875-rqw6 (CVE-2026-102894, CVSS 9.1). The SAML callback at /auth/saml/callback accepted a SAML response without verifying its signature, issuer, audience or time conditions, so anyone who could reach the endpoint could log in as an existing user, administrators included. The advisory states this works even when SAML SSO is not configured, and that no configuration change mitigates it. Versions 0.7.1 up to but not including 2.2.2 are affected. CVE-2026-102894 was not in the KEV catalog as of the November 9 catalog release.

How the GPUStack bypass works

The root cause is a design assumption, not a parsing bug. GPUStack used the network source of a request as an authentication signal. That assumption holds only when nothing sits in front of the service. Put a reverse proxy on the same host and every request is "local". Accept a forwarding header from any client and the client chooses its own source address. We explain the general pattern, and why it keeps recurring, in what a localhost authentication bypass is.

The fix in 2.2.0 removed the loopback auto-admin path entirely and hardened client IP and forwarding header handling. Per the advisory, a real-client-IP header is now only accepted from an authenticated, trusted gateway.

The impact is broader than one server. An AI cluster manager holds credentials for every worker node it controls and, often, for the cloud accounts it provisions GPUs in. An attacker who mints a wildcard admin API key keeps access after the vulnerable code is patched, because the key itself remains valid. That is why patching alone does not close this incident.

What to do now

  1. Upgrade. Move to GPUStack 2.2.2 or later. Version 2.2.0 fixes CVE-2026-102895, but only 2.2.2 fixes the SAML bypass in CVE-2026-102894. A separate record, CVE-2026-58658 (CVSS 8.2), covers unauthenticated access to worker /serveLogs and /debug endpoints in versions through 2.2.1, with a fix in commit 4e20551. Confirm which release includes that commit before you treat a worker as fixed.
  2. If you cannot upgrade today, apply the advisory's workarounds: set force_auth_localhost=true so loopback requests must authenticate, strip any client-supplied X-GPUStack-Real-IP header at the edge proxy, and keep the API off untrusted networks behind a VPN or edge authentication.
  3. Hunt for persistence. In the GPUStack console, review every API key, especially admin keys with full scope that nobody on your team created. Review the user list for unknown accounts and the inference backend list for custom backends you did not define. The advisory's in-the-wild case involved attacker-created custom backends.
  4. Review proxy logs for requests to /v2/inference-backends/from-yaml and /auth/saml/callback from addresses you do not recognize. Note that on a same-host proxy setup, GPUStack's own logs will show loopback for everything, so the proxy logs are the useful record.
  5. Rotate secrets. If a vulnerable instance was reachable, assume worker credentials and any stored cloud provider keys were read. Rotate them and review the cloud account for GPU instances or other resources you did not launch. Our guide on how to secure a self-hosted AI inference server covers the checklist in more detail.
  6. Check worker hosts for unexpected processes and outbound connections, since code execution happens on workers, not only the server.

What to watch next

Watch for a public write-up from ulex.fr with indicators of compromise, for CISA adding CVE-2026-102894 to KEV, and for scanning activity against exposed GPUStack consoles. This is the second AI model serving platform with an exploited authentication bypass on CISA's list this autumn, after LiteLLM CVE-2026-59822 in September. If your vulnerability program does not yet track AI model servers as a separate asset class, read why AI infrastructure needs vulnerability management.

Sources