CVE-2026-102895: GPUStack login bypass exploited, fix in 2.2.0 (use 2.2.2)

GPUStack, an open-source manager for GPU clusters that serve AI models, has a critical login bypass that attackers are already using. CVE-2026-102895 lets anyone who can reach the server pass as the built-in administrator, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 9 November 2026 with a due date of just three days later, 12 November. Version 2.2.0 fixes it. A second critical GPUStack flaw, CVE-2026-102894, needs version 2.2.2, so the safe target is 2.2.2 or newer.

Key points

• CVE-2026-102895 (CVSS 9.8, Critical) affects GPUStack before 2.2.0: a request that looks like it comes from 127.0.0.1 is treated as the built-in administrator.
• The advisory data in NVD says exploitation was observed in the wild against a GPUStack 2.1.1 deployment; CISA added the CVE to KEV on 9 November with a due date of 12 November 2026.
• Access gives full control: user and model changes, persistent administrator API keys, worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml.
• Version 2.2.0 fixes CVE-2026-102895; CVE-2026-102894, a separate SAML login bypass (CVSS 9.1) in versions 0.7.1 up to 2.2.2, is fixed in 2.2.2.
• The default setting that allows the bypass is force_auth_localhost=false.

What to do

• Who is affected: every GPUStack server older than 2.2.0 for CVE-2026-102895, and every server from 0.7.1 to before 2.2.2 for CVE-2026-102894. If you run 2.1.1 or older, you are affected by both.
• Fix: upgrade to 2.2.2 or newer (the container image or the gpustack package, whichever way you installed it). CISA's due date for federal agencies is 12 November.
• If you cannot upgrade today: SecurityOnline, which summarised the vendor advisories, lists two stopgaps: set force_auth_localhost=true, and strip any X-GPUStack-Real-IP header at the reverse proxy; and block outside access to the /auth/saml/callback path until 2.2.2. These are interim measures and we have not tested them.
• Check whether you were hit: CISA marks this KEV entry as needing forensic triage. Look for administrator API keys or users you did not create, models or inference backends you did not deploy (especially custom backends defined by YAML), unexpected outbound connections from worker nodes, and any use of the from-yaml endpoint in your logs.
• If you find signs: rotate every credential GPUStack could see, including cloud-provider keys and worker secrets, and rebuild the workers. NVD says the bug exposes "worker and cloud-provider secrets", so assume they are known.
• Exposure: if GPUStack sits behind a reverse proxy on the same host, the vulnerable check sees every outside request as coming from 127.0.0.1. Do not rely on the proxy as a defence.

What happened

NVD published CVE-2026-102895 on 4 November 2026 using GitHub's advisory (GHSA-gj9m-f8ph-pmhr). Its description says that before 2.2.0, the function get_current_user in gpustack/api/auth.py treated a request from the loopback address as the built-in administrator whenever force_auth_localhost was false, "which was the default". A remote request could look local in two ways. If GPUStack ran behind a reverse proxy on the same machine, the proxy's own connection came from 127.0.0.1. Or the attacker could simply send a loopback value in the X-GPUStack-Real-IP header, which the client-address logic accepted.

The result, per NVD, is "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". The record adds that "exploitation was observed in the wild against a 2.1.1 deployment" and that the issue is fixed in 2.2.0. The CVSS 3.1 vector is network, low complexity, no privileges, no user interaction, high impact on confidentiality, integrity and availability.

On 9 November CISA added it to KEV as "GPUStack Improper Authentication Vulnerability" with a due date of 12 November, only three days after the addition. CISA marks ransomware use as "Unknown" and sets forensic triage to "Yes".

SecurityOnline reports that researcher Javier Sixto of ulex.fr reported attacks in the wild, and that the intruders used custom backends to run reverse shells on target hosts. We could not open the vendor advisory itself, so we treat those details as that outlet's account.

A second flaw was disclosed the same week. NVD published CVE-2026-102894 on 4 November: from 0.7.1 until 2.2.2, the /auth/saml/callback endpoint decoded SAML XML and issued a gpustack_session login token without verifying the signature, issuer, audience or time conditions, "even when SAML was not configured". Any network client could claim to be an existing user, including an administrator, or create a new account. NVD scores it 9.1 (Critical) and says it is fixed in 2.2.2. SecurityOnline reports no exploitation of this one yet, and CISA's catalog did not list it when we checked on 11 November.

Background

GPUStack describes itself as an open-source GPU cluster manager for AI model serving and GPU instance provisioning. It configures inference engines such as vLLM, SGLang and TensorRT-LLM and manages clusters across on-premises servers, Kubernetes and cloud providers. A control plane like this holds exactly the things an attacker wants: expensive GPUs, API keys and cloud credentials.

"Trust localhost" shortcuts are a familiar mistake. They are meant for a developer running a tool on their own laptop, but they break when a reverse proxy or container network puts every request on the loopback interface, and when a header that should be set by a trusted proxy can be set by anyone. The current GPUStack source reflects the lesson: a comment in auth.py says X-Real-IP is "deliberately not read" because nothing in the gateway chain overwrites it, so any client could assert an arbitrary source address.

Related reading: we covered an exploited login bypass in OpenSSH on Alpine and the Fireworks AI breach.

How it works

The bypass needs no exploit code in the usual sense, only an assumption that proves wrong:

1. The server checks where a request came from.
2. If the source is the loopback address, and force_auth_localhost is false, it returns the built-in administrator.
3. The "source" is computed from the network peer or a header. Behind a same-host proxy, the peer is always the proxy at 127.0.0.1. Otherwise the header can simply be forged.
4. Once admin, the caller can create a permanent API key, read secrets, and post a YAML definition for a custom inference backend. That backend runs commands on workers, which is how a login bypass becomes remote code execution.

The fix in 2.2.0, as SecurityOnline summarises it, removed the loopback auto-admin rule and tightened how IP headers are read. We confirmed that the current source no longer reads X-Real-IP, but we did not review the release's full change list.

What it means

For teams running GPUStack: upgrade now, to 2.2.2 rather than 2.2.0, and treat any server that was reachable from outside and older than 2.2.0 as possibly compromised. The cloud-provider secrets it holds make the blast radius larger than the cluster itself.

For platform and security teams: this is a reminder to inventory AI serving stacks that were deployed by research or ML teams outside normal change control. Those tools often ship with permissive defaults for local use.

For vendors: defaults matter. The advisory data says the bypass worked because a setting left at its default of false trusted loopback requests.

What we don't know yet

• How many GPUStack servers are exposed to the internet, and how many were compromised. We found no public numbers.
• Who is exploiting the bug, and what they do after getting in beyond the reverse shells SecurityOnline mentions.
• Whether CVE-2026-102894 is being exploited. Nothing reported so far says it is.
• The exact content of the GitHub advisory and release notes, which we could not open directly from this run; check them before you apply the fix.

What to watch next

• A CISA KEV entry for CVE-2026-102894, if exploitation appears.
• Further GPUStack releases after 2.2.2 and any statement from the maintainers about the attacks.
• Scans from threat-intelligence firms that count exposed GPUStack servers.
• Similar reports about other self-hosted model-serving and GPU-management tools.

Sources

• NVD: CVE-2026-102895
• NVD: CVE-2026-102894
• CISA Known Exploited Vulnerabilities catalog, entry for CVE-2026-102895
• GPUStack security advisory GHSA-gj9m-f8ph-pmhr
• GPUStack on GitHub (README and auth.py)
• SecurityOnline: Attackers Exploit Critical GPUStack Authentication Bypass in the Wild