GPUStack Authentication Bypass (CVE-2026-102895): Is Your AI Server at Risk?

What is known as of 10 November 2026

GPUStack is a platform for running and managing AI models across GPU servers. CVE-2026-102895 is an improper authentication flaw in its API. The vendor advisory (GHSA-gj9m-f8ph-pmhr) rates it Critical, CVSS 9.8, and lists all versions before 2.2.0 as affected, with 2.2.0 as the first fixed release.

In affected versions the server treats a request that appears to come from the same machine (a loopback address) as the built-in administrator, with no credentials. There are two ways to look like that. If a reverse proxy on the same host forwards traffic to GPUStack on 127.0.0.1, every remote request arrives from a loopback address. Or a remote client can send an X-GPUStack-Real-IP header claiming to be 127.0.0.1.

The advisory lists the consequences: full administrative access, creation of persistent admin API keys that work from any IP address, exposure of worker credentials and cloud-provider secrets, and code execution on worker hosts through the inference-backends from-yaml endpoint. CISA's catalogue entry describes the same outcomes.

CISA added CVE-2026-102895 to the Known Exploited Vulnerabilities catalogue on 9 November 2026 with a due date of 12 November 2026. That deadline is a US federal obligation under BOD 26-04 and does not bind UK organisations, but it is a fair indication of how CISA rates the urgency. CISA records ransomware use as unknown.

Check whether you are affected

You are in scope if you run a GPUStack server on a version earlier than 2.2.0. The risk is highest where the server's API or web interface can be reached from the internet or from networks you do not fully trust, and where a reverse proxy on the same machine passes traffic to GPUStack over 127.0.0.1. Both routes in the advisory work over the network, so a private-looking deployment behind a flat internal network is not automatically safe.

The commands below only read information. Run them on the GPUStack server host with an account that can see the install.

1. Find the installed version. For a pip-based install, run the command shown against the Python environment GPUStack uses. For a container install, list your containers and read the image tag. If the tag is latest, compare the image's version with the release list on the GPUStack GitHub releases page instead.
   bashCopy

   pip show gpustack

   bashCopy

   docker ps --format "table {{.Names}}\t{{.Image}}"

2. If a reverse proxy sits in front of GPUStack, look at how it forwards traffic. The nginx example searches its configuration for upstream targets. A proxy_pass pointing at 127.0.0.1 or localhost means the proxy and GPUStack share a host, which is the first route described in the advisory. Other proxies have equivalent settings.
   bashCopy

   grep -rn "proxy_pass" /etc/nginx/

3. Note whether the server is reachable from outside your trusted network, and who can reach it. You will need that answer again when deciding whether to check for compromise.

If you cannot upgrade today: reduce exposure first

The most dependable stopgap is to make the server unreachable to anyone who should not be using it. Put it behind a VPN or an authenticating gateway, or restrict it with firewall rules to known addresses. The advisory lists this alongside two configuration workarounds for affected versions.

These are interim measures for versions before 2.2.0 and are no substitute for the upgrade. Changing GPUStack's settings means restarting the server, which interrupts model serving, so schedule it. Try it on a non-production instance first if you have one, because the effect on any internal components that call the API from the same host has not been documented by the vendor.

1. Require authentication for loopback requests. Add force_auth_localhost: true to the GPUStack YAML configuration file. The 2.1 documentation also describes the --force-auth-localhost flag for gpustack start and a GPUSTACK_FORCE_AUTH_LOCALHOST environment variable. The default is false, which is why affected servers trust loopback traffic. Restart the server so the setting takes effect.
   yamlCopy

   force_auth_localhost: true

2. Strip any client-supplied X-GPUStack-Real-IP header at your outermost proxy so that outside users cannot set it. The nginx directive shown clears it before the request is passed on. Apply the equivalent in whichever proxy or load balancer you use, then reload its configuration.
   textCopy

   proxy_set_header X-GPUStack-Real-IP "";

3. Confirm the change by sending an unauthenticated request to the API from a machine outside the host, with and without the header. Both should now be refused instead of returning data. Use only your own server for this test.

Upgrade to a fixed release

The advisory's fixed version is 2.2.0, which removed the loopback auto-admin path and hardened how client IP and forwarding headers are handled. We would not stop there. GPUStack's release notes show that 2.2.0 and 2.2.1 still carry a separate SAML authentication bypass and missing authorisation checks fixed in 2.2.2, and release 2.3.0 (23 October) lists three further security fixes. Aim for the current stable release, and use 2.2.2 as the floor. Avoid release-candidate and development builds in production, as the vendor's upgrade guidance advises.

The details below follow the Docker upgrade documentation for GPUStack 2.x. Installs created before version 0.7 need the vendor's migration guide first, and pip or script installs need the procedure for your install method from the GPUStack documentation. Upgrading the server restarts it, so expect a short outage for the API and web interface. Plan the workers afterwards, because the vendor says to upgrade the server first and then each cluster's workers.

1. Stop the GPUStack server and back up its data. For the embedded database in a container install, that is the directory /var/lib/gpustack/postgresql/data inside the container. If you use an external database, use its normal backup method. Do this before any upgrade, because the upgrade is not designed to be rolled back by simply downgrading.
2. Pull the target image. Replace YOUR_TARGET_TAG with the stable version tag you have chosen from the releases page.
   bashCopy

   docker pull gpustack/gpustack:YOUR_TARGET_TAG

3. Stop and remove the old container, then start a new one from the updated image using exactly the same arguments and volumes as the original. Keep your original start command to hand for this.
   bashCopy

   docker stop gpustack
   docker rm gpustack

4. Once the server is healthy on the new version, upgrade the workers in each cluster following the vendor's cluster upgrade procedure.
5. Check the result: the web interface and pip or image details should show the new version, and the verification request from the previous section should still be refused without credentials.

If the server was exposed: check for compromise

Upgrading closes the door. It does not remove anything an attacker did while it was open, and the advisory specifically says the flaw allows creation of persistent admin API keys that work from any source IP. We would not assume an upgrade revokes keys that already exist. CISA's catalogue entry also lists forensic triage as part of the required action. If your server was on an affected version and reachable by anyone untrusted, work through the checks below, ideally before you change anything that would erase evidence, and involve your security or IT support team if you find anything.

Be realistic about logs. The forged header does not normally appear in default web-server access logs, so a clean log does not prove a clean server. The checks of GPUStack's own state are more reliable than log searches.

• Users and API keys: review the user list and every API key in the GPUStack interface. Look for administrator accounts or keys you did not create, particularly keys with unrestricted scope.
• Inference backends: look for custom inference backends you do not recognise. The advisory reports attackers in the wild creating custom backends that launched reverse shells on workers.
• Worker hosts: look for unexpected processes, outbound connections to unfamiliar addresses, new scheduled tasks or new user accounts on each GPU worker.
• Proxy and server logs: search for requests to the from-yaml endpoint from addresses that are not yours. The example searches nginx access logs and needs adapting to your log location and proxy.
  bashCopy

  grep -rn "inference-backends/from-yaml" /var/log/nginx/

• Secrets: if there is any sign of access, or you cannot rule it out, rotate everything GPUStack could expose - admin and user API keys, worker credentials, cloud-provider keys and model-registry tokens. Rotate after you have contained access, or the attacker's keys can simply be re-used.

What has been reported about exploitation

The vendor advisory states that the flaw has been observed exploited in the wild against a GPUStack 2.1.1 deployment, where attackers created custom backends that ran reverse shells. The advisory credits Javier Sixto (ulex.fr) with reporting that activity. CISA's inclusion in the Known Exploited Vulnerabilities catalogue is further evidence of exploitation, but neither source names an affected organisation, and we are not naming or guessing at any.

What is not established in the sources we checked: who is behind the attacks, how widespread they are, whether ransomware is involved (CISA lists that as unknown) or how many servers are compromised. We will revise this section if credible new reporting appears.

A separate SAML flaw to deal with in the same upgrade

GPUStack 2.2.2 also fixes CVE-2026-102894, a different flaw in the SAML single sign-on callback that can allow authentication bypass and account takeover. The vendor's 2.2.2 release notes put it in versions 0.7.1 to 2.2.1. Secondary reporting says it does not require SAML to be configured, that the vendor has not been seen to confirm that detail, and that blocking the /auth/saml/callback route at your firewall is a stopgap. We have found no evidence of exploitation of this one so far, but absence from CISA's list is not proof that it has not been used. It is a good reason not to stop at 2.2.0.