GPUStack auth bypass CVE-2026-102895 added to CISA KEV
At a glance
| Severity | CRITICAL |
|---|---|
| CVSS | CVE-2026-102895: 9.8 |
| EPSS (30-day exploit probability) | CVE-2026-102895: 0.3% |
| In CISA KEV (exploited) | Yes, due 2026-11-12 |
| Vendor | GPUStack |
| CVE IDs | CVE-2026-102895 |
Primary-source details
- CVE-2026-102895: CVSS 9.8 (Critical), per NVD; fixed in gpustack gpustack: 2.2.0 (NVD); added to the CISA KEV catalog on 2026-11-09, remediation due 2026-11-12; vendor advisory (listed by NVD).
CISA has added a critical authentication bypass in GPUStack, the open-source GPU cluster manager for AI model serving, to its Known Exploited Vulnerabilities catalog, according to the CISA KEV entry. The flaw, CVE-2026-102895, affects GPUStack versions before 2.2.0, carries a CVSS score of 9.8 and is being exploited in the wild. Federal agencies must act by 2026-11-12, and every other GPUStack operator should treat that date as a guide.
What happened
GPUStack decides who is an administrator in a function called get_current_user in gpustack/api/auth.py. Before version 2.2.0, a request that appeared to come from the loopback address was treated as the built-in administrator whenever force_auth_localhost was false, which was the default setting.
The weakness is in how the server decides where a request came from. A remote request could look as if it originated from 127.0.0.1 because the client IP logic accepted either a same-host reverse proxy peer or a client-supplied X-GPUStack-Real-IP loopback value. In plain terms, an attacker could claim to be local and the server believed it.
NVD describes what the bypass allows without any credentials:
- user and model changes;
- creation of persistent administrator API keys;
- disclosure of worker and cloud-provider secrets;
- code execution through
POST /v2/inference-backends/from-yaml.
NVD records that exploitation was observed against a 2.1.1 deployment. NVD published the CVE on 2026-11-04 and CISA added it to KEV on 2026-11-09.
Am I affected?
- Affected: gpustack gpustack before 2.2.0.
- Fixed: version 2.2.0, according to NVD. The upstream project published a security advisory, a pull request and a commit for the fix.
Any deployment older than 2.2.0 is in scope. Exposure matters most: an instance reachable from the internet, or placed behind a reverse proxy on the same host, is the scenario the description points to. CISA tells operators to evaluate each asset’s internet exposure.
Technical details
The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no privileges, no user interaction, and high impact on confidentiality, integrity and availability. NVD maps the flaw to CWE-287 (improper authentication), CWE-290 (authentication bypass by spoofing) and CWE-346 (origin validation error).
CISA names it “GPUStack Improper Authentication Vulnerability”. The catalog lists known ransomware campaign use as unknown. The vendor advisory text could not be retrieved for this article, so the details above come from NVD and the CISA entry. The identity of the attackers and the number of affected victims have not been disclosed.
Why this matters
This section is analysis, not new reporting. A GPUStack server sits close to expensive GPU capacity, model weights and the credentials used to provision cloud instances. Administrator access plus a code execution endpoint means an attacker can run commands on the platform and read the worker and cloud-provider secrets it holds. Those secrets can let an intruder move from the AI cluster into the wider cloud account, so the damage may outlast the GPUStack patch itself.
Because the bypass needs no credentials and the vulnerability is in KEV, patch within hours rather than days for any internet-reachable instance. Upgrading closes the hole but does not remove access an attacker already created.
What to do
- Inventory every GPUStack server and note its version. Anything below 2.2.0 needs action.
- Upgrade to 2.2.0 or later. If you cannot upgrade immediately, follow the vendor’s mitigation instructions, as CISA’s required action says, and remove internet exposure of the management interface in the meantime. Where mitigations are unavailable, CISA says to discontinue use of the product.
- Hunt for compromise before and after patching. Review access logs for requests carrying an
X-GPUStack-Real-IPheader with a loopback value, and for any request to/v2/inference-backends/from-yaml. - Audit administrator accounts and API keys. Delete any you did not create, since persistent administrator keys survive an upgrade.
- Rotate worker credentials and cloud-provider secrets stored in or reachable from GPUStack if the instance was exposed.
- Check cloud audit logs for unfamiliar instance launches or key use from the credentials GPUStack held.
- Follow CISA’s forensics triage requirements referenced in the KEV entry if you find signs of exploitation, and tell your incident response team.
Detection ideas
Any of the following is worth investigating: administrator actions from addresses that are not your operators; new model or inference backend definitions you did not request; outbound connections from GPU workers to unknown hosts after a YAML backend was created; and API keys created outside your normal change process. No indicators of compromise have been published for this vulnerability.
The KEV deadline of 2026-11-12 applies to US federal civilian agencies, but the entry signals that exploitation is real and ongoing, so private organisations running GPUStack should move on the same timeline.
Related coverage
Sources
- CISA Known Exploited Vulnerabilities catalog entry
- NVD: CVE-2026-102895
- GPUStack fix pull request #5346
- GPUStack fix commit
- GPUStack security advisory GHSA-gj9m-f8ph-pmhr
