CVE-2026-102895 · AI agents & MCP
NO FIX YET · SEE WHAT TO DO
GPUStack, a GPU cluster manager for AI model serving, trusts requests that appear to come from localhost when force_auth_localhost is off, which is the default. A remote attacker can forge a loopback source using a reverse proxy peer or a spoofed X-GPUStack-Real-IP header, gaining administrator rights to change users and models, read worker and cloud secrets, and run code through the inference backend YAML endpoint.
first public Jul 31, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Any deployment of GPUStack before 2.2.0 that is reachable from a network the attacker can reach, particularly where a same-host reverse proxy forwards traffic and force_auth_localhost was left at its default of false. Deployments that only accept connections from trusted local clients, or that set force_auth_localhost to true, are less exposed. The sources say exploitation was observed against a 2.1.1 deployment.
Not affected if force_auth_localhost-true, version-2.2.0-or-later
Who cares ai-inference, gpustack, reverse-proxy, self-hosted
gpustack --version; versions below 2.2.0 are affected.force_auth_localhost is set to true in the GPUStack configuration; the default is false, so unset means exposed.2.2.0.GPUStack is an open-source GPU cluster manager for AI model serving and GPU instance provisioning. Prior to 2.2.0, get_current_user in gpustack/api/auth.py treated a loopback request source as the built-in administrator when force_auth_localhost was false, which was the default. A remote request could appear to originate from 127.0.0.1 because client_ip_getter accepted a same-host reverse proxy peer or a client-supplied X-GPUStack-Real-IP loopback value. The bypass allowed unauthenticated administrative access, including user and model changes, persistent administrator API-key creation, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml. Exploitation was observed in the wild against a 2.1.1 deployment. This issue is fixed in version 2.2.0.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.