GPUStack flaw hands attackers admin access without a password, now exploited

What happened

GPUStack is an open-source tool for managing clusters of graphics cards (GPUs) that companies and teams use to run their own AI models, such as large language models. Versions before 2.2.0 contain a login flaw that lets an attacker on the network become administrator without a username or password. The flaw is tracked as CVE-2026-102895.

The project’s developers published a security advisory on GitHub on July 31, 2026 and fixed the issue in version 2.2.0. The record reached the US vulnerability database NVD on November 4, 2026.

This is not a theoretical threat. According to the developers’ advisory, attackers exploited the flaw against a version 2.1.1 installation, where they created their own custom “backends” that opened remote access to the server (a so-called reverse shell). The exploitation was reported by Javier Sixto (ulex.fr). The US agency CISA added the flaw to its KEV catalog of actively exploited vulnerabilities on November 9, 2026, and ENISA’s European vulnerability database EUVD lists it as exploited since the same day.

Why it is dangerous

This is an authentication flaw. By default, GPUStack automatically treated any request that appeared to come from the same machine (address 127.0.0.1, known as localhost) as a request from the built-in administrator. Think of a security guard who lets anyone into the vault as long as they claim to have come from inside the building, without checking their badge.

The catch is that this “origin” is easy to fake. If GPUStack runs behind a reverse proxy (such as nginx) on the same server, which is a common setup, every request from the internet reaches GPUStack from 127.0.0.1. According to the developers, the attacker then needs nothing special at all. The second route is a forged header in the request that makes it look as if it came from localhost.

The attacker needs no login and no user interaction, only network access to GPUStack. According to the developers’ advisory, they can then:

view and change users, models, worker nodes and configuration,
create persistent administrator API keys that keep working from any IP address afterwards,
read worker credentials and secrets for cloud and other providers,
use admin features (creating a custom inference backend) to run their own code on the GPU servers.

The CVSS score of 9.8 out of 10 (CVSS 3.1) comes from the project’s security advisory on GitHub and means critical severity: a simple network attack with no login required. The CISA KEV catalog lists flaws that CISA has evidence are being exploited. The EPSS score, an estimate of the likelihood of exploitation in the next 30 days, is only about 0.33%, but with confirmed attacks that number matters far less than the fact that the flaw has already been exploited.

Who is affected

All GPUStack installations running versions before 2.2.0 (the gpustack package) are affected. Exploitation was confirmed against version 2.1.1.

You will find GPUStack wherever an organization hosts its own AI models on its own hardware, for example on company servers with GPUs or in Kubernetes clusters. The highest risk applies to installations reachable from the internet and to those sitting behind a reverse proxy on the same server. The developers describe that setup as the typical self-hosted deployment.

CISA notes that this is an open-source component that may also be used in other products. If an outside vendor delivered your AI solution, ask them whether it includes GPUStack and which version.

Versions 2.2.0 and later are not affected, and neither are organizations that do not use GPUStack.

How to check if you are affected

Check the version on the server where GPUStack runs. All commands below only read data and change nothing. For a pip installation:

pip show gpustack

With Docker, look at the image and its version tag. If the tag is latest or unclear, check the version inside the container:

docker ps --format '{{.Names}} {{.Image}}' | grep -i gpustack
docker exec CONTAINER_NAME pip show gpustack

On Kubernetes, list the images of your deployments:

kubectl get deploy,statefulset,daemonset -A -o wide | grep -i gpustack

If the version is lower than 2.2.0, you are vulnerable. Also check whether force_auth_localhost is set to true in the configuration or startup parameters. If it is not, the vulnerable default applies. A reverse proxy on the same server that forwards requests to 127.0.0.1 or localhost increases the risk. The first command shows GPUStack’s startup parameters, the second looks for such a setup in nginx. If you use a different proxy, check its configuration.

ps aux | grep -i '[g]pustack'
grep -rnE "proxy_pass[[:space:]]+https?://(127\.0\.0\.1|localhost)" /etc/nginx/ 2>/dev/null

How to fix it

The flaw is fixed in GPUStack 2.2.0. According to the developers, it removes the automatic admin rights for localhost requests and hardens the handling of the client IP address. Recommended order of steps:

If GPUStack is reachable from the internet, restrict access immediately, for example to VPN only or behind authentication at the gateway.
Back up the GPUStack database and configuration.
Upgrade the server and all workers to version 2.2.0 or later. Version 2.2.0 checks for mismatched server and worker versions, so upgrade all parts together.
After the upgrade, confirm the version with the commands from the previous section.
Check whether the system was compromised and rotate API keys and credentials (see the next section).

For a pip installation, the upgrade may look like this. With Docker or Kubernetes, use an image at version 2.2.0 or later and redeploy the containers.

pip install --upgrade "gpustack>=2.2.0"

If you cannot upgrade right away, the developers list these temporary measures:

set force_auth_localhost=true so GPUStack requires login even for localhost requests,
configure the reverse proxy or gateway so external traffic can never look local, and strip any client-supplied X-GPUStack-Real-IP header at the edge,
keep the GPUStack API off untrusted networks, behind a VPN or edge authentication.

Neither the upgrade nor the temporary measures remove API keys an attacker has already created. CISA requires US federal agencies to fix the flaw by November 12, 2026, which is a sensible benchmark for you too.

What if you may already be compromised

If your GPUStack was reachable from the internet or an untrusted network before the upgrade, assume someone may already have abused it. The developers describe attackers creating their own inference backends that opened remote access to the server. Check:

the list of inference backends: custom backends you did not create,
API keys: unknown keys, especially those with full permissions,
users, models, workers and configuration: unexpected changes or new admin accounts,
GPU servers: unknown processes and unusual outbound connections,
reverse proxy logs: requests to /v2/inference-backends/from-yaml from unknown IP addresses.

For nginx, this command searches both current and older compressed logs. With a different proxy, look for the same path in its logs.

zgrep -n "inference-backends/from-yaml" /var/log/nginx/access.log*

The attacker could have read worker credentials and secrets for cloud providers. Rotate them after the upgrade, even if you find no traces of an attack.

If you find an unknown backend, key or suspicious process, disconnect the affected servers from the network, preserve the logs and bring in an incident response specialist. Code running on the workers may have given the attacker a path further into your network.

Sources

Articles are put together by an AI agent from public sources (vendors, CISA, ENISA, NVD, SK-CERT, NÚKIB), and version numbers and CVEs are checked against them automatically. Always confirm the steps in the vendor advisory before touching production.