CVE-2026-102895 GPUStack Vulnerability: Patch to 2.2.0

If you run GPUStack before version 2.2.0, upgrade now. CVE-2026-102895 lets a remote attacker act as the built-in administrator without logging in, and it is being exploited.

CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 2026-11-09. The federal due date is 2026-11-12.

What happened

GPUStack is an open-source GPU cluster manager for AI model serving and GPU instance provisioning. According to the NVD record, the function get_current_user in gpustack/api/auth.py treated a loopback request source as the built-in administrator. That happened when force_auth_localhost was false, which was the default.

A remote request could look like it came from 127.0.0.1. The client_ip_getter accepted a same-host reverse proxy peer, or a client-supplied X-GPUStack-Real-IP loopback value. Either one was enough to skip authentication.

The NVD entry lists three weaknesses: CWE-287, CWE-290 and CWE-346.

Who is affected and which version fixes it

Every GPUStack release before 2.2.0 is affected. The NVD record says the issue is fixed in 2.2.0. It also says exploitation was observed in the wild against a 2.1.1 deployment.

You are most exposed if the server sits behind a reverse proxy on the same host. In that setup every proxied request arrives from a loopback address. You are also exposed if the server is reachable from the internet and trusts the X-GPUStack-Real-IP header.

How serious it is and whether it is exploited

The CVSS score is 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). That means network reachable, low complexity, no privileges and no user interaction.

Per the NVD record, the bypass allows:

• 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

The API key point matters most. An attacker who creates an admin key keeps access after you patch, unless you find and delete it. The stolen cloud-provider secrets also stay valid until you rotate them.

CISA's KEV entry is on its catalog. Known ransomware use is listed as Unknown, so check the catalog for updates.

What to do now

1. Find your GPUStack servers

List every instance, including test boxes and containers. Then read the installed version.

pip show gpustack
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i gpustack
docker exec <container-name> pip show gpustack

Anything below 2.2.0 needs action. Decide for each one whether it is reachable from the internet.

2. Upgrade to 2.2.0

Follow the vendor's release notes for v2.2.0 and security advisory. For a pip install, this is the basic step:

pip install --upgrade 'gpustack>=2.2.0'

The fix commit removes the localhost trust. From 2.2.0 on, the --force-auth-localhost option is a deprecated no-op, and localhost callers are always authenticated. You do not need to set it after upgrading. The pull request also changes the admin password reset CLI to use a short-lived JWT minted from the local server secret.

If you cannot upgrade today, restrict access at the firewall to trusted addresses only, or take the server off the internet. On versions before 2.2.0, you can also start GPUStack with --force-auth-localhost enabled as a temporary stopgap. The NVD record says the bypass applied when force_auth_localhost was false, the default. Treat this as a stopgap only. Upgrading is the real fix.

3. Check for signs of abuse

Search your reverse proxy logs for the code-execution endpoint and the spoofable header. Adjust the path for your proxy.

grep -i 'inference-backends/from-yaml' /var/log/nginx/access.log*
grep -i 'X-GPUStack-Real-IP' /var/log/nginx/*.log*

Two limits apply. Default nginx and most proxy access logs do not record request headers. The second command only finds hits if a custom log format captures that header. Also, the same-host reverse-proxy path needs no header at all, because the proxy peer already looks like loopback. So the from-yaml search and the user and API-key review below are the more reliable checks.

Any POST to from-yaml from an address you do not know is a red flag. Treat the host as compromised if you find one.

Then review inside GPUStack:

1. List all users and remove any you did not create.

2. List all API keys and delete admin keys you do not recognize.

3. Review models and inference backends for recent changes.

After patching, confirm the fix on your own instance only. Send a request with the header X-GPUStack-Real-IP: 127.0.0.1 to an API path that normally needs login. It should now return an authentication error.

curl -i -H 'X-GPUStack-Real-IP: 127.0.0.1' https://<your-host>/<any-authenticated-api-path>

4. Rotate what the server could read

Assume anything stored in GPUStack was exposed if the server was reachable while vulnerable. Rotate:

• worker secrets

• cloud-provider credentials and keys

• all GPUStack API keys

CISA's required action also points to its BOD 26-04 guidance and its "Forensics Triage Requirements." Federal agencies must follow both. Everyone else can use them as a checklist. Where mitigations are unavailable, CISA says to discontinue use of the product.

Quick decision guide

What learners can take from this

This bug is a classic trust mistake. The code assumed that "from localhost" meant "trusted," but a reverse proxy or a forged header can fake that. The same pattern shows up in other bypasses, like the one in our Barracuda ESG authentication bypass write-up.

If you want to practice triage like this, log review and incident response are core skills in the CompTIA CySA+ (CS0-003) voucher. A good lab is to set up a proxy in front of a test app and see what client IP the app actually trusts.

Our 5 active cyber threats for US enterprises post covers other issues worth tracking.

Sources

• NVD: CVE-2026-102895

• GPUStack fix commit 53f42a6

• GPUStack pull request 5346