SURIQ
GPUStack CVE-2026-102895 is an unauthenticated admin takeover in the open-source GPU cluster manager, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026. Upgrading closes the hole. It does not remove anything an attacker already planted, and the fix has been available since the July 31 advisory, so any exposed server that sat unpatched for those 101 days should be treated as possibly compromised.
The bug class matters more than the product. GPUStack decided who you were by where your request appeared to come from. Put a reverse proxy on the same box for TLS, which is how most people run a self-hosted web app, and every visitor on the internet arrives from 127.0.0.1. That is not an exotic setup. It is the default way to publish a service.
Why does a reverse proxy turn GPUStack into an open admin panel?
Before version 2.2.0, GPUStack treated any request from a loopback address as the built-in administrator, because the force_auth_localhost setting defaulted to false. According to the project's security advisory, a client can reach that state two ways: through a proxy that connects from loopback, or by sending a forged X-GPUStack-Real-IP header claiming to be local.
The first path needs no trick at all. Header-stripping rules at a web application firewall do nothing against it, because the attacker sends a normal request and your own proxy supplies the loopback address. Teams that read the advisory, added a header filter, and stopped there are still exposed if Nginx or Caddy sits on the same host.
We have seen this mistake before. In July we covered Gitea's Docker image trusting a login header from anyone, and the root is identical: network position or a client-supplied header standing in for a credential. Authentication and account-takeover flaws were the third-largest bug class in our own intel ledger over the last 90 days, at 1,422 entries, behind cross-site scripting and command injection.
Who is exposed
-
Affected: GPUStack releases before 2.2.0 (the pip package
gpustack). CVSS 3.1 score 9.8. -
Fixed: 2.2.0. Loopback no longer means administrator, and the server is stricter about which forwarding headers it believes.
-
Exploitation: listed in CISA KEV on November 9, with a federal patch deadline of November 12. The advisory says exploitation was seen against a 2.1.1 deployment, reported by Javier Sixto of ulex.fr, where attackers registered custom inference backends that opened reverse shells.
-
Most at risk: any instance reachable from an untrusted network, and especially one fronted by a proxy on the same host.
The timeline above is the real story. The advisory went public on July 31. CISA confirmed exploitation on November 9, and agencies have until November 12. A GPU cluster manager is the kind of tool a research team stands up once and forgets, so the gap between "fix exists" and "fix applied" is often months.
Target 2.2.2, not 2.2.0
A second GPUStack flaw, CVE-2026-102894 (CVSS 9.1), sits in the SAML single sign-on callback. TheHackerWire reported on November 5 that the callback accepts identity claims without validating signatures, issuer, or audience, and that the endpoint answers even on instances that never configured SAML. It is fixed in 2.2.2. It was not in KEV and had no indexed public exploit as of that report. If you are patching for the KEV entry anyway, going straight to 2.2.2 saves you a second maintenance window.
What an attacker leaves behind after admin access
This is the part a version bump does not touch. Per the advisory, admin access lets an attacker create API keys scoped to everything that work from any IP address, read worker credentials and cloud-provider secrets, change users and models, and reach code execution on worker hosts through the admin-only POST /v2/inference-backends/from-yaml endpoint. Every one of those outlives the upgrade.
So the response has two halves. Patch, then audit as if the box was owned:
-
API keys. List every key in the admin console. Revoke any with a wildcard scope you did not create, and any you cannot tie to a person or service.
-
Inference backends. Review every custom backend definition. A backend you did not register is the persistence mechanism the advisory describes, and its command runs on your GPU workers.
-
Users. Look for new admin accounts or changed roles.
-
Cloud and worker secrets. Rotate any cloud-provider credential GPUStack stored, then check that provider's audit trail for activity from addresses you do not recognise. Stolen cloud keys are how a GPU server compromise becomes a cloud bill.
-
Worker hosts. Check for outbound connections and processes that do not belong to a model server.
Can't upgrade today? Turn off the loopback trust
The advisory's interim mitigation is to make loopback requests authenticate like any other, strip the client IP header at the edge, and keep the API off untrusted networks. The block below shows the setting and the access-log patterns worth searching on the reverse proxy in front of GPUStack.
force_auth_localhost: true grep 'POST /v2/inference-backends/from-yaml' /var/log/nginx/access.log grep -i 'x-gpustack-real-ip' /var/log/nginx/access.log
The second search only finds something if your proxy logs that header, and most default log formats do not. A clean result there proves nothing. The backend-creation search is the stronger signal, because legitimate use of that endpoint is rare and usually tied to a known admin. If your logs do not go back to the summer, the audit list above is your only evidence, which is why it comes first.
Where this leaves self-hosted AI tooling
GPUStack joins Langflow and LiteLLM on the list of AI infrastructure tools that have reached KEV this year. These tools are often deployed by machine-learning teams outside the usual patch process, hold cloud credentials, and run arbitrary model-serving code by design. That combination makes an admin bypass worth far more than its CVSS score suggests. Inventory every AI serving or orchestration tool your teams run, put each one behind real authentication, and make sure its logs reach someone who looks at them. Continuous vulnerability detection across the whole fleet is how a forgotten GPU node gets found before an attacker finds it.