Since November 9, 2026, the U.S. agency CISA has listed the GPUStack vulnerability CVE-2026-102895 in its catalog of actively exploited vulnerabilities. GPUStack manages GPU servers on which companies run their own language models, for example for internal AI assistants or for searching their own documents. Before version 2.2.0, GPUStack treats certain requests from the network like requests from the administrator, without a password. This affects IT management, digital transformation leads and AI teams in industry and commerce, as well as service providers that operate GPU servers for clients.
GPUStack servers prior to version 2.2.0 should be updated to 2.2.2 or later, because only 2.2.2 also closes a second critical vulnerability. If the interface was reachable via a reverse proxy, check administrator keys, users and inference backends, and rotate the stored credentials. Where nobody has updated the AI platform since the pilot, clarify now who operates it.
| Vulnerability | Affected Versions | Corrected in | Exploitation |
|---|---|---|---|
| CVE-2026-102895, Administrator privileges without login, CVSS 3.1 score of 9.8 (GitHub) | All versions prior to 2.2.0 | Version 2.2.0, June 18, 2026 | Actively exploited according to the vendor, listed by CISA since November 9, 2026 |
| CVE-2026-102894, SAML Authentication Without Signature Verification, CVSS 3.1 score of 9.1 (GitHub) | Version 0.7.1 up to but not including 2.2.2 | Version 2.2.2, July 24, 2026 | No known exploitation |
What Is Known About the GPUStack Vulnerability
GPUStack is open-source software that distributes language models across several GPU servers and serves them through a common interface. Before version 2.2.0, every request that appears to come from the local machine counts as a request from the built-in administrator. The setting that requires a login for these requests as well is switched off by default. If a reverse proxy runs in front of GPUStack on the same server, as many installations do, every request from the network appears to come from the local machine. A second route uses a header that the caller sets themselves (GitHub Advisory GHSA-gj9m-f8ph-pmhr).
According to the advisory, these privileges allow attackers to modify users and models, create permanently valid administrator keys, and read the stored login credentials for GPU servers and cloud accounts. Attackers use their own inference backends to execute code on the GPU servers. The developers observed an attack on an installation running version 2.1.1 in which the attackers used such backends to establish remote access to the servers. GitHub, as the CVE-assigning authority, rates the vulnerability at 9.8 out of 10 points according to CVSS 3.1.
CISA added CVE-2026-102895 to its database on November 9, 2026, and requires U.S. federal agencies to install the update and conduct a forensic analysis by November 12 (CISA KEV). A second vulnerability, CVE-2026-102894, affects SAML-based authentication. Prior to version 2.2.2, GPUStack accepted authentication credentials without verifying the signature, even if SAML was not configured (NVD).
days is how long the fixed version 2.2.0 had already been available on November 10, 2026. According to the vendor, the attack hit an installation running version 2.1.1.
PyPI and GitHub Advisory: GPUStack, November 2026
What the Vulnerability Means for Your Local AI
Version 2.2.0 was released on PyPI on June 18, 2026; the current version, 2.3.0, was released on October 23, 2026. Anyone still affected by this vulnerability has not updated the platform for months. A typical example is a pilot project set up by a small team that continues to run with real data afterward.
GPU servers are usually located on the corporate network, often on the same network as file servers and ERP systems. Anyone who executes code on these servers can use them to attack other systems. In addition, there are the stored keys for model sources and cloud accounts, which remain valid even after an update following a breach.
A model calculation for an automotive supplier shows the order of magnitude. It assumes one GPUStack server running version 2.1.1 behind nginx, four GPU servers, six models and an internal assistant for 300 users. We estimate update and hardening at 1 to 2 person-days. Checking keys, users, backends and logs takes an estimated 2 to 3 person-days, rotating all credentials 1 to 2 person-days. Without findings, that adds up to 4 to 7 person-days. If the check finds traces of a breach, rebuilding the five servers from verified images adds an estimated 6 to 12 person-days, for a total of 10 to 19 person-days.
GPUStack Update, Audit, or Rebuild: Your Options
| Option | Effort | Costs | Risk |
|---|---|---|---|
| Update to 2.2.2 or later; the current version is 2.3.0 | Hours per server, recreate container | Internal Time | Minimal; however, keys from a previous attack remain valid |
| Transition without an update, requiring authentication for local requests and access only via VPN | Hours | Low | Does not address the SAML vulnerability CVE-2026-102894 |
| Check for a breach and rotate all credentials | 3 to 5 person-days; if findings are positive, an additional 6 to 12 person-days for rebuilding (estimate) | Medium | Without logs from the reverse proxy, the result remains uncertain |
| Replace the management layer, for example, with vLLM using its own gateway on Kubernetes | 10 to 20 person-days (estimate) | Moderate to high | Applications have to move to new endpoints |
| Do nothing | None | None for now | Attackers gain administrator privileges, access credentials, and the ability to execute code on the GPU servers |
According to the advisory, until you update, this setting helps: force_auth_localhost=true. On the reverse proxy, also remove the header X-GPUStack-Real-IP. The vendor's instructions are authoritative. Test updates in a test environment first. How we plan and operate local language models is described on the page AI Consulting with On-Premises LLM and RAG.
Which path is right for which business?
For a pilot that only the AI team can reach from its own network, the update and a look at the administrator keys are enough. The case is different for an installation before 2.2.0 that was reachable behind a reverse proxy from the corporate network or the internet. There, the check and key rotation belong in this week, and if there are traces of a breach, a rebuild from verified images.
The bigger decision concerns operations. GPUStack closed the vulnerability in June, and the attacked version was from March. Like the ERP, an AI platform needs someone who reads security advisories and installs updates. We recommend assigning this responsibility before the next expansion, internally or to a service provider. The same applies to the gateway in front of the models, as the post Securing the AI Gateway Following the LiteLLM Attack shows.
Security Check for On-Premises AI in Five Business DaysWe record every server on which you run language models, such as GPUStack, vLLM, Ollama and AI gateways, with version, network exposure and stored credentials. For GPUStack, we check administrator keys, users and inference backends for traces of a breach. For each server you receive a classification into update, reinstall or replace with estimated effort, and a proposal for who updates the platform in future. You then decide whether your team runs it or you outsource operations.
Frequently Asked Questions
Is the GPUStack update to version 2.2.0 sufficient?
Version 2.2.0 addresses CVE-2026-102895; the SAML vulnerability CVE-2026-102894 is addressed in version 2.2.2. After the update, recreate the container; otherwise, the old process will continue to run. The update does not remove keys that an attacker may have created previously.
How much does it cost to audit and clean up a GPUStack cluster?
In our model calculation with five servers, the check including update and key rotation takes an estimated 4 to 7 person-days. With traces of a breach and a rebuild, it is 10 to 19 person-days. The difference comes from the available logs and the number of stored credentials.
How can I tell if our GPUStack has been compromised?
Indicators include administrator keys that no one on the team has created, new users, and inference backends from unknown YAML files. The manufacturer does not specify any fixed identifying characteristics. If you suspect a problem, take the server offline and back up the logs before making any changes.
The Next Step
torck designs, builds, and operates local language models for industry and commerce, either on its own hardware or in a German data center. You can find out how we do this on the page AI Consulting, On-Premises LLM, and RAG. For more background information, see On-Premise LLMs for Sensitive Data, Ollama in the Workplace and Securing the AI Gateway. Schedule an Initial Consultation.
German 
English 
French