An explainer for a vulnerability in GPUStack (an open-source manager that runs AI models on GPU clusters and provisions GPU instances) that lets unauthenticated parties act as administrator. It covers what happens, who is affected and how to respond, from the defender's side and without attack steps.
- CVE
- CVE-2026-102895 (GitHub advisory GHSA-gj9m-f8ph-pmhr)
- Severity
- CVSS v3.1 9.8 (Critical). Same value in the advisory, the CVE record and NVD
- Type
- Improper authentication (CWE-287). The advisory also lists authentication bypass by spoofing (CWE-290) and origin validation error (CWE-346)
- Preconditions
- Unauthenticated; network reach to GPUStack is enough. Per the advisory, default settings are affected
- Affected
- pip gpustack before 2.2.0
- Fix
- gpustack 2.2.0
- Dates
- Advisory: 31 July 2026 / CVE record: 4 November 2026
- Exploitation
- Exploitation in the wild reported in the advisory. Added to CISA KEV on 9 November 2026 (due 12 November)
Risk of waiting
According to the advisory, an unauthenticated party can change users, models and worker settings, and create administrator API keys that work from any source address. Worker and cloud-provider credentials can be read, and combined with administrator-only functionality this leads to code execution on worker hosts. The advisory says exploitation in the wild was observed. CISA marks forensic triage as required for this KEV entry.
What the vulnerability is
With default settings (force_auth_localhost is false), GPUStack treats a request from the same machine (loopback) as the built-in administrator. It is meant to save authentication effort for local use. The problem is that what decides "is it the same machine" can be influenced from outside.
According to the advisory there are two paths to administrator without authentication. The first is a reverse proxy on the same host: once the proxy forwards to GPUStack, even external requests appear to GPUStack to come from loopback. This is a common self-hosted layout and needs no header or credential. The second is a request forwarding header; the advisory says a client-supplied value can make a request look like loopback. This site does not describe how to exploit it.
Before (earlier than 2.2.0)
- A loopback source becomes administrator without authentication
- Behind a same-host reverse proxy, external traffic looks like loopback
- A forwarding header can fake the source
After (2.2.0) changes
- The path that treats loopback as administrator is removed
- Client-IP and forwarding-header handling is hardened
- A real-client-IP header is accepted only from an authenticated, trusted gateway
Scope
| Item | Detail |
|---|---|
| Product | GPUStack (open-source GPU-cluster manager) |
| Affected package | pip gpustack |
| Affected versions | Before 2.2.0 (advisory and CVE record) |
| Fixed version | 2.2.0 |
| Real-world harm | Advisory: exploitation in the wild observed against v2.1.1 |
| What can happen | All administrator actions (changing users, models, workers), creating administrator API keys, reading worker and cloud-provider credentials, code execution on workers (per the advisory and KEV) |
- Per the advisory, default settings are affected.
- The advisory lists only the pip package gpustack. If you installed it another way, such as a container image, check your provider's information for the version.
How to check whether you are affected
Check the GPUStack version
Check the installed gpustack version. Anything before 2.2.0 is affected. If you have production, staging and development environments, check each one (Asset inventory checklist).
Check whether it is reachable from outside
Check whether the GPUStack port, or the reverse proxy in front of it, is reachable from untrusted ranges such as the internet. Per the advisory, the flaw works through a same-host reverse proxy, so being behind a proxy is not evidence of safety.
Check the force_auth_localhost setting
Check whether force_auth_localhost is true. Per the advisory, the default is false, which leaves the vulnerable path open.
What to do today
Update to 2.2.0 (top priority)
Update gpustack to 2.2.0 or later. The KEV due date is 12 November 2026.
Until then, narrow the entrance
The advisory's workarounds are below. None replaces updating.
- Set force_auth_localhost to true so loopback requests also need authentication.
- Make sure the reverse proxy or gateway cannot make external traffic look like loopback, and strip any client-supplied X-GPUStack-Real-IP header at the edge.
- Keep the API off untrusted networks, behind a VPN or edge authentication.
After updating, audit administrator API keys
Per the advisory, a created administrator API key works from any source address afterwards. Updating does not remove it, so list the existing API keys and delete any whose creator or creation time you do not recognise. Look especially at keys created before the update.
Revoke and reissue credentials
The advisory says worker credentials and cloud-provider secrets can be read. Revoke and reissue what you registered in GPUStack: worker connection details, cloud-provider keys, model-download tokens and similar. As this site's addition, reissue them even if you find no trace of abuse. See The vulnerability remediation playbook and Security basics: .env and API keys.
Review settings and workers
Check for unfamiliar custom backends, users and model settings. On workers, check for unfamiliar processes and outbound connections. Because exploitation has been confirmed, treat any unfamiliar configuration as a possible sign of compromise. If you find anything suspicious, isolate that worker and consider rebuilding it.
Exploitation status
- The advisory states that exploitation in the wild was observed against a v2.1.1 deployment. The exploitation is credited to a third-party reporter.
- CISA added it to KEV (the catalogue of vulnerabilities with confirmed exploitation; version 2026.11.09) on 9 November 2026, with a due date of 12 November. Use in ransomware campaigns is listed as unknown, and forensic triage as required.
- The NVD record has the status Analyzed. CVSS v3.1 is 9.8, the same as the advisory and the CVE record.
- The advisory credits several reporters who reported the vulnerability independently.
This site's view: do not leave things unauthenticated because they are internal or behind a proxy
This is less a coding slip than a flawed design assumption. "A request from my own machine is me" collapses the moment you put a reverse proxy in front. A reverse proxy on the same host is also a widely used way to add HTTPS and publish a service, so a setup that feels protected becomes the entrance.
An AI platform's admin console holds the model runtime, GPU resources and cloud credentials in one place. If it accepts unauthenticated requests, the damage does not stop at one machine; it spreads outward through the cloud credentials. Protect admin consoles and admin APIs with authentication, not with location or source address. The same class of problem appears when a design trusts forwarding headers (XFF spoofing and trusted proxies). After updating, the job is not finished until you have cleaned up the API keys that were created and the credentials that could have been read.
Sources
- GPUStack — GHSA-gj9m-f8ph-pmhr: Authentication bypass via trusted loopback source (published 31 July 2026; affected versions, fix, workarounds, exploitation report)
- CVE.org — CVE-2026-102895 (published 4 November 2026; before 2.2.0, CVSS 9.8)
- NVD — CVE-2026-102895 (status Analyzed)
- CISA KEV — Known Exploited Vulnerabilities Catalog (added 9 November 2026, due 12 November)
Last verified: 10 November 2026.
Read next
- Practice: The vulnerability remediation playbook / Asset inventory checklist
- Deciding: Prioritising with CVSS, EPSS and KEV
- Authentication: XFF spoofing and trusted proxies / Authentication vs authorization
- Keys: Security basics: .env and API keys / What is CVSS?