The US Cybersecurity and Infrastructure Security Agency (CISA) added the GPUStack flaw CVE-2026-102895 to its Known Exploited Vulnerabilities (KEV) catalog on November 9. The bug lets attackers act as the administrator of a GPUStack server without any credentials, giving them access to users, models, worker credentials and cloud keys, and ultimately code execution on the GPU hosts. All versions before 2.2.0 are affected. US federal agencies must respond by November 12. Anyone running GPUStack to serve their own AI models should check now which version is deployed and how the server can be reached.
CVE-2026-102895: what is behind the GPUStack flaw
GPUStack is an open-source GPU cluster manager released under the Apache 2.0 license. Teams use it to distribute large language models, image and audio models across several GPU servers via inference engines such as vLLM or SGLang, and to expose them through an OpenAI-compatible API. Since version 2.2.0, GPUStack can also provision on-demand GPU instances that are reachable over SSH. That often makes a GPUStack server the central control point for expensive hardware, model weights and API keys.
According to the developers’ security advisory GHSA-gj9m-f8ph-pmhr, the flaw sits in the get_current_user function in gpustack/api/auth.py. It automatically treated any request whose source was considered a loopback address (127.0.0.1) as a request from the built-in administrator, as long as the force_auth_localhost option was set to false. That was the default. The idea was simple: someone working locally on the server should not have to log in.
The problem was how GPUStack determined the source. According to the advisory, the responsible function, client_ip_getter, could be made to report “127.0.0.1” in two ways, neither of which required any credentials.
Path 1: a reverse proxy on the same host
In a typical self-hosted setup, a reverse proxy such as Nginx runs on the same machine in front of GPUStack and forwards requests via proxy_pass http://127.0.0.1:<port>. From GPUStack’s point of view, every request from the internet then arrives from the TCP peer 127.0.0.1. As a result, the automatic loopback-admin branch fired for every external request, with no crafted header needed. The developers explicitly call this the “canonical” self-hosted shape.
Path 2: a forged X-GPUStack-Real-IP header
In addition, an attacker could send their own X-GPUStack-Real-IP: 127.0.0.1 header. That too could cause the request to be classified as local. This put installations without a proxy at risk as well, unless the header was stripped on its way to the server.
What an attack can lead to
According to the advisory, both paths lead to full, unauthenticated administrative access over the network. Specifically, the developers list the ability to:
- enumerate and modify users, models, workers and configuration,
- mint persistent admin API keys with the scope
["*"]that work from any IP address afterwards, - read worker credentials as well as cloud and provider secrets,
- create custom inference backends via the admin-only
POST /v2/inference-backends/from-yamlendpoint and thereby execute code on worker hosts.
The second point is particularly tricky: an API key created by an attacker survives the update. Anyone who patches without reviewing existing keys may leave the door open for an intruder.
Exploitation in the wild
The advisory states that the flaw has already been exploited against a deployment running version 2.1.1. Attackers created custom inference backends there that launched reverse shells, giving them remote control of the machine. According to the advisory, the in-the-wild exploitation was reported by Javier Sixto (ulex.fr). The vulnerability itself was reported independently by Nikko Enggaliano, Wei Yunzhou, and Rui Yang and Haoyu Wang (Johns Hopkins University).
CISA added CVE-2026-102895 to the KEV catalog on November 9 together with three other flaws, including the FreeSWITCH flaw CVE-2026-116779 and the OpenSSH “SSHole” bug. The deadline for US federal agencies is November 12, and CISA also requires a forensic triage to determine whether systems were compromised before patching. Whether the flaw is used in ransomware campaigns is unknown, according to CISA.
Severity and timeline
GitHub, acting as the CVE numbering authority, assigned a CVSS 3.1 score of 9.8 (“critical”): network attack vector, low complexity, no privileges and no user interaction required. The weakness classes assigned are CWE-287 (improper authentication), CWE-290 (authentication bypass by spoofing) and CWE-346 (origin validation error).
The timeline stands out. The developers merged the pull request “remove localhost auto-admin bypass” (#5346) as early as May 19, 2026, and version 2.2.0 with the fix shipped on June 18. The advisory was published on July 31, the CVE appeared in the US National Vulnerability Database (NVD) on November 4, and the KEV entry followed five days later. Anyone stuck on a version before 2.2.0 for months has been exposed the whole time, and at least since the advisory it has been public how the attack works. The current release is 2.3.1, published on November 11.
What operators should do now
The fix is included in GPUStack version 2.2.0. According to the advisory, it removes the implicit loopback administrator entirely and hardens the handling of client-IP and forwarding headers. For operators, that results in a short checklist:
- Update: upgrade to 2.2.0 or later, ideally to the current release.
- Interim workaround: if you cannot update immediately, set
force_auth_localhost=trueso that local requests also require authentication. - Check the proxy: strip the
X-GPUStack-Real-IPheader from client requests at the edge and make sure external traffic cannot arrive as loopback. - Limit exposure: do not expose the API directly to the internet; run it behind a VPN or edge authentication.
Beyond the developers’ guidance, any server that was reachable from the network before the update deserves a check for signs of compromise. This is a general recommendation, not a requirement from the advisory: review all API keys and admin accounts and revoke unknown ones, compare existing inference backends against your own configuration, investigate unusual outbound connections from workers, and rotate stored cloud and provider credentials as a precaution. On GPU servers it is also worth watching utilization: foreign processes on expensive accelerators often show up first on the bill.
Analysis
The GPUStack flaw follows a familiar pattern: a convenience feature (“local means trusted”) becomes an entry point once the network environment changes. Putting a reverse proxy in front of a service is generally considered good practice, yet here that very step undermined the security assumption. The advisory spells out the lesson itself: authentication must not be derived from a request’s network source, and headers carrying the “real” client IP should only be accepted from a trusted gateway.
For AI infrastructure, the case is a warning sign. Self-hosted model-serving tools are growing fast, often run in research and development environments with looser processes, and still concentrate valuable resources: GPUs, models, data and access keys for cloud services. As with this month’s Patch Tuesday November 2026, the rule applies: once a flaw is in the KEV catalog, it is no longer a theoretical risk. GPUStack operators should check their version, exposure and API keys today.
