Actively exploited Security news
GPUStack: behind a same-host reverse proxy, anyone on the internet is admin
Running GPUStack to serve your own AI models? Check your version. Attackers are using CVE-2026-102895 to run code on GPU servers, and CISA added it to its exploited list on 9 November 2026 – even though the fix in version 2.2.0 shipped back in June 2026.
Key points
- GPUStack before 2.2.0 treats any request from 127.0.0.1 as the built-in administrator unless force_auth_localhost is enabled – and it is off by default.
- Behind a reverse proxy on the same host, every internet request looks local. According to the vendor, a spoofed X-GPUStack-Real-IP header achieves the same thing.
- With no password, an attacker takes over cluster management, creates persistent API keys and runs commands on GPU workers through a custom inference backend. The vendor has confirmed exploitation, and CISA added the flaw to KEV on 9 November 2026.
- The fix shipped in 2.2.0 on 18 June 2026, so only unpatched installs are exposed. After upgrading, review API keys and backends.
Vulnerabilities: CVE-2026-102895
What happened
GPUStack is an open-source (Apache 2.0) GPU cluster manager that companies and research teams use to serve their own AI models, for example through vLLM or SGLang. The project has more than 6,000 stars on GitHub.
On 9 November 2026, CISA added CVE-2026-102895 to its Known Exploited Vulnerabilities (KEV) catalog and gave US federal agencies until 12 November 2026 to fix it. The bug itself isn't new: the fix is in version 2.2.0, released on 18 June 2026, and the vendor described it in advisory GHSA-gj9m-f8ph-pmhr on 31 July 2026. Installs that haven't been updated since the summer are the ones at risk.
According to the vendor, attackers exploited the flaw against a version 2.1.1 deployment, creating custom inference backends that launched reverse shells on the servers.
How serious is it?
| Item | Value |
|---|---|
| CVSS 3.1 score | 9.8 (critical), scored by the vendor |
| Weakness | CWE-287 improper authentication, CWE-290 authentication bypass by spoofing, CWE-346 origin validation error |
| Exploitation | active (vendor, CISA) |
| Automatable | yes (CISA SSVC) |
| Known ransomware use | unknown, per CISA |
Whoever controls GPUStack controls the whole cluster: users, models, workers and configuration. The vendor says an attacker can read worker credentials and cloud provider secrets and run code on the GPU servers.
Technical details
The flaw sits in get_current_user in gpustack/api/auth.py. When force_auth_localhost is false – the default – the function serves any request it believes came from loopback (127.0.0.1) as the built-in administrator, with no password.
The vendor describes two ways to make an internet request look local:
- A reverse proxy on the same host. If nginx, Caddy or another proxy runs on the same machine as GPUStack, it connects to the app from 127.0.0.1. Every internet request then looks local, with no special header needed.
- A forged header. A client can send its own
X-GPUStack-Real-IPheader with a loopback address, and the app trusts it.
The vendor puts the root cause down to treating a request's network source as proof of identity. With admin rights, an attacker can create a custom backend through POST /v2/inference-backends/from-yaml and get code running on the workers. Version 2.2.0 removes the automatic loopback admin and tightens client-IP and forwarding-header handling.
We don't publish exploitation steps.
Who is affected
According to the vendor and NVD, all GPUStack versions before 2.2.0 are vulnerable. Internet-facing installs behind a same-host reverse proxy are the most exposed. CISA notes that GPUStack is an open-source component other products may use, so if it came bundled with another product, ask your supplier which version you have.
People who simply use AI services aren't directly affected; the cluster administrator needs to act.
How to tell if you were compromised
The vendor hasn't published specific indicators of compromise (IP addresses, file names). Based on how the attack works, we recommend checking for:
- API keys nobody on your team created – the vendor says attackers create persistent admin keys that work from any IP.
- Inference backends you don't recognise, especially ones imported from YAML.
- Users and configuration changes with no matching admin work.
- Proxy and application logs: internet requests carrying
X-GPUStack-Real-IP, admin actions with no login. - Worker hosts: unknown processes and outbound connections (reverse shells) running under the GPUStack account or from backend containers.
You can pull IPs and domains out of exported logs with our IOC extractor, which runs entirely in your browser. If you can't rule out compromise, treat the cluster as breached: rebuild the servers from a clean install and rotate every secret GPUStack could reach, including cloud keys.
What to do
- Find the version of every GPUStack install.
- Upgrade to GPUStack 2.2.0 or later.
- If you can't upgrade right away, set
force_auth_localhost=true, as the vendor advises, so local requests must authenticate too. - Strip client-supplied
X-GPUStack-Real-IPheaders at the proxy and make sure the proxy doesn't make internet traffic look local (vendor guidance). - Keep the API off the open internet – put it behind a VPN or authentication at the edge (vendor guidance).
- After upgrading, work through the compromise checks above and revoke any suspicious API keys.
Timeline
Updates
- 10 November 2026 – first version.
FAQ
Our GPUStack is internal only. Does this affect us?
Less so, but yes. The attack works from anywhere the API is reachable, including a compromised machine on the same network. Patch internal installs too.
We don't use a reverse proxy. Are we safe?
Not necessarily. The vendor describes a second path: a forged X-GPUStack-Real-IP header sent straight from the client. The reliable fix is upgrading to 2.2.0, or setting force_auth_localhost=true as a stopgap.
We've upgraded. Are we done?
Only if the server wasn't compromised before. Upgrading doesn't remove API keys or backends an attacker may already have created. Work through the checks in How to tell if you were compromised.
How do I check which GPUStack version we run?
The GPUStack web UI shows the version. For a pip install, run pip show gpustack; for containers, check the image tag you deployed.
Sources
Spotted a mistake? Let us know and we will correct it openly.
Related
Actively exploited
Exploited UnrealIRCd flaw CVE-2026-114713 lets any user run commands with server authority
On Friday 13 November 2026 CISA added CVE-2026-114713, a flaw in the UnrealIRCd IRC server, to its Known Exploited Vulnerabilities catalog and gave federal agencies just three days to fix it. The bug in the labeled-response module lets any user on a network with two or more linked servers inject server-to-server commands that are executed with server authority, such as KILL or GLINE. The project's maintainer called it the most critical UnrealIRCd issue in 15 years. The fix shipped on 7 November as version 6.2.7.1 and as a hot-patch that needs no restart.
Actively exploited
Openwave Webtop Media Transcoder: an old document converter flaw is now exploited
Run Openwave Webtop webmail for your customers? Media Transcoder versions before 1.1.22.0 ignore the file type restrictions the administrator has set. The vendor has confirmed attacks and CISA added the flaw to its exploited list on 10 November, even though the vendor says the fixed release shipped back in December 2021.
Actively exploited
IBM Aspera Faspex: an authorization flaw hands users full admin rights, and it is already exploited
Use IBM Aspera Faspex 5 to move large files? On 7 November 2026 IBM fixed CVE-2026-123218, which lets an ordinary signed-in user take full administrative control. Two days later CISA added it to its list of known exploited vulnerabilities and gave US federal agencies only until 12 November to fix it.