CISA Adds GPUStack Auth Bypass Flaw to KEV Catalog, Patch Due Today

Federal civilian agencies have until the end of today, November 12, 2026, to patch or mitigate an authentication-bypass flaw in GPUStack, the open-source GPU cluster manager many teams use to self-host AI model inference. CISA added the bug, tracked as CVE-2026-102895, to its Known Exploited Vulnerabilities (KEV) catalog on November 9 after confirming it is already being exploited, and the agency's standard three-business-day clock under Binding Operational Directive 26-04 runs out today. Any organization running GPUStack — not just federal agencies — should treat this as a same-day fire drill: the flaw carries a CVSS score of 9.8 and lets an unauthenticated attacker become an administrator.

What CISA added to the KEV catalog

CISA's Known Exploited Vulnerabilities catalog is a running list of software flaws the agency has evidence are being actively exploited. Every entry carries a fixed remediation deadline that U.S. federal civilian executive branch agencies are legally required to meet under Binding Operational Directive 26-04 (the directive that replaced the older BOD 22-01 KEV mandate). CISA's own feed lists the GPUStack entry with a dateAdded of 2026-11-09 and a dueDate of 2026-11-12 — today.

The catalog's short description for CVE-2026-102895 is specific about what the bug allows: "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." CISA lists the vendor and product both as "GPUStack," marks known ransomware use as "Unknown," and requires forensic triage before or alongside remediation — a flag CISA attaches when it believes a system may already be compromised, not just vulnerable.

Because GPUStack is open-source infrastructure rather than a single vendor's shrink-wrapped product, CISA's notes field adds a line it uses for community and open-source components: agencies should follow BOD 26-04 guidance for the underlying service or discontinue use if no mitigation is available. The notes also point directly to GPUStack's own GitHub security advisory and to the CVE's NVD record, which is where most of the technical detail actually lives.

What GPUStack is, and who runs it

GPUStack is an open-source GPU cluster manager built to run AI inference workloads — the kind of self-hosted stack that sits in roughly the same niche as Ollama or a self-managed vLLM deployment, but aimed at teams that want to pool GPUs across on-premises hardware, Kubernetes, or cloud instances and manage it all from one control plane. According to its own GitHub repository, it configures and orchestrates inference engines including vLLM, SGLang, and TensorRT-LLM (plus custom engines), serves LLM, voice, image, and video models through OpenAI-compatible APIs, and supports accelerators from NVIDIA, AMD, Ascend, Hygon, MThreads, and several other hardware vendors. It is pitched at internal IT teams and service providers running "Model-as-a-Service" setups, and it can also hand out SSH-accessible GPU instances for development and fine-tuning work.

That self-hosted, admin-heavy design is exactly why an authentication bypass in GPUStack is more dangerous than it might sound from the name alone. A GPUStack server typically holds API keys, worker credentials, cloud-provider secrets for provisioning GPU capacity, and the ability to push arbitrary inference-backend configuration to every worker node it controls. Breaking authentication on that server doesn't just expose chat logs — it hands an attacker the keys to the whole cluster.

What the flaw actually allows

GPUStack's own security advisory, GHSA-gj9m-f8ph-pmhr, lays out the root cause in detail. The get_current_user function in gpustack/api/auth.py grants built-in administrator rights to any request whose source is treated as "loopback" (i.e., coming from the server itself) when a setting called force_auth_localhost is left at its default value of False. Two things can make a request look like loopback traffic even when it isn't:

• A same-host reverse proxy that connects to GPUStack over 127.0.0.1 — which, by design, makes every remote request behind it appear local to GPUStack.
• A forged X-GPUStack-Real-IP: 127.0.0.1 header, which a remote client can simply send itself.

In other words, the server was trusting a network-position signal — or a client-controllable HTTP header — as proof of identity. GPUStack's advisory says this was verified end-to-end against a specific commit in the codebase, confirming it's a real, exploitable path and not a theoretical configuration error.

Once an attacker clears that bar, the advisory lists what built-in admin access hands them: the ability to enumerate and modify users, models, workers, and configuration; create persistent administrator API keys scoped to everything (["*"]); read worker credentials and cloud or provider secrets; and call admin-only endpoints such as POST /v2/inference-backends/from-yaml to push a custom backend definition — which CISA's own description notes is a path to code execution on worker hosts.

What's confirmed exploited versus what's reported

CISA's KEV listing is itself the confirmation that matters most here: by definition, nothing goes into the KEV catalog without evidence of active exploitation, and CISA marks required forensic triage on this entry, which generally signals agencies should check for signs of prior compromise rather than assume a clean patch solves everything retroactively. CISA's own feed does not, however, publish exploit mechanics or a specific victim profile — for that level of detail, GPUStack's own advisory is the better primary source.

GPUStack's advisory states plainly that the bypass "has been observed in the wild" against a deployment running version 2.1.1, where attackers created custom inference backends that executed reverse shells on the affected host. The advisory does not publish proof-of-concept code. Beyond that one documented incident, broader claims about how many organizations have been hit, or exactly how widespread exploitation is, are not something either CISA or GPUStack has published — treat any more specific exploitation numbers you see elsewhere as reported, not confirmed, unless they cite CISA or GPUStack directly.

The fix itself is confirmed by the vendor: GPUStack's advisory says version 2.2.0 removes the loopback auto-admin path entirely and hardens how the server handles client-IP detection and forwarded headers, so neither a same-host proxy nor a forged header can silently grant admin rights anymore.

Affected versions, fixes, and the related SAML bug

The table below summarizes both GPUStack advisories relevant to this KEV addition — the actively exploited authentication bypass, and a second, separately tracked authentication flaw in GPUStack's SAML single sign-on handling that is not confirmed exploited but is fixed by the same version upgrade.

The second entry, CVE-2026-102894, is documented in a separate GPUStack advisory, GHSA-62m9-f875-rqw6. It describes GPUStack's SAML login callback accepting a posted SAML response and issuing a session token without ever calling the library function that actually verifies the response's signature — meaning an attacker with network access to the callback endpoint can impersonate any identity, including an existing administrator, regardless of whether SAML is even configured on that server. GPUStack's advisory credits a University of California, Berkeley research team with reporting it and says a working exploit exists but has only been shared privately with the maintainers; it is not in CISA's KEV catalog and is not described by either GPUStack or CISA as actively exploited. The practical upshot for admins is simple: both issues are closed by the same upgrade. Fixing only CVE-2026-102895 (version 2.2.0) still leaves the SAML bypass open until you reach at least version 2.2.2.

Who's legally required to act, and who else should care

CISA's KEV deadlines are a legal requirement only for U.S. federal civilian executive branch agencies, under Binding Operational Directive 26-04. That directive is the mechanism, not the audience limit: CISA's required-action text for this entry explicitly tells agencies to follow BOD 26-04 guidance for cloud services or discontinue use of the product if no mitigation is available, and to perform forensic triage where applicable — language CISA reserves for KEV entries it considers higher-risk.

For everyone else — the state and local governments, universities, startups, and enterprises that make up most of GPUStack's actual user base, given that it's a self-hosted open-source tool rather than something agencies would deploy themselves — the deadline isn't binding, but the risk calculus is identical. A CVSS 9.8, unauthenticated, remotely exploitable admin takeover with documented in-the-wild use is exactly the kind of flaw KEV inclusion exists to flag for the broader internet, not just government networks. If you're running GPUStack to serve models internally, the fact that today is a federal deadline is a useful forcing function, not the reason to patch.

What GPUStack admins should do today

If your organization runs GPUStack anywhere — on-prem, in Kubernetes, or in the cloud — here's the concrete checklist for today, in order:

1. Check your version. Anything before 2.2.0 is vulnerable to CVE-2026-102895; anything before 2.2.2 is also vulnerable to the SAML bypass, CVE-2026-102894.
2. Upgrade to 2.2.2 or later. This is the single fix that closes both the actively exploited loopback bypass and the SAML callback issue in one move.
3. If you can't upgrade immediately, apply GPUStack's documented workarounds for CVE-2026-102895: set force_auth_localhost=true, strip any client-supplied X-GPUStack-Real-IP header at your edge or reverse proxy, and confirm your proxy configuration can't make external traffic appear as loopback to the GPUStack process.
4. For the SAML issue, there's no configuration workaround per GPUStack's advisory — block access to /auth/saml/callback at a reverse proxy or ingress controller until you can upgrade to 2.2.2.
5. Don't expose the GPUStack API or admin UI directly to the internet. Put it behind a VPN or an authenticated gateway regardless of patch status; this single change would have blocked both documented attack paths.
6. Treat already-exposed instances as potentially compromised. CISA's forensic-triage flag on this entry is a reasonable cue to check for unexpected admin API keys, unfamiliar inference-backend definitions, or worker processes you didn't create — the documented in-the-wild exploitation created custom backends specifically to run reverse shells.
7. Rotate credentials after patching. If there's any chance the instance was internet-facing before today, rotate worker credentials and any cloud-provider secrets GPUStack had access to, and revoke API keys you don't recognize.

This KEV addition follows the same pattern Pandromeda has covered recently with Outlook and with FreeSWITCH's actively exploited flaw — a real-world exploitation report turning into a hard federal deadline within days. It's also a reminder that self-hosted AI infrastructure is now squarely in the same patch-management conversation as the rest of the month's broader vulnerability load: the tools teams stood up quickly to run their own models carry the same authentication risks as any other exposed admin surface, and need the same discipline around version tracking and network exposure.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage