GPUStack auth bypass exploited in the wild (CVE-2026-102895)

Actively exploited in the wild - CVE-2026-102895 is a critical authentication bypass in GPUStack before 2.2.0 that grants unauthenticated attackers full administrative control, including remote code execution and disclosure of cloud-provider secrets. Patched in 2.2.0; update immediately.

Overview

GPUStack is an open-source GPU cluster manager used to serve AI models and provision GPU instances. In versions before 2.2.0, the get_current_user function in gpustack/api/auth.py treated any request that appeared to come from the local machine (loopback) as the built-in administrator. This behavior was active whenever force_auth_localhost was false, which was the default configuration.

The flaw is that GPUStack trusted too many ways of deciding a request came from localhost. The client_ip_getter logic accepted a reverse proxy peer on the same host, and it also trusted a client-supplied X-GPUStack-Real-IP header carrying a loopback value. A remote attacker could therefore make their request look like it originated from 127.0.0.1 and be logged in as the administrator without any credentials.

Impact

Any unauthenticated attacker who can reach the GPUStack API can act as the built-in administrator. That means they can create or modify user accounts and models, and they can mint persistent administrator API keys that survive a restart or credential change. The attacker can also read worker and cloud-provider secrets stored by GPUStack, exposing infrastructure credentials. Most seriously, the /v2/inference-backends/from-yaml endpoint accepts administrator-submitted configuration, giving the attacker a path to execute code on the GPUStack host.

Because the request comes over the network with no privileges and no user interaction, the CVSS score is 9.8 (Critical). Exploitation has been observed in the wild against a 2.1.1 deployment.

Remediation and Mitigation

• Upgrade to GPUStack 2.2.0 or later. This is the definitive fix. The current authentication logic no longer treats a proxy peer or a client-supplied header as proof of local origin.
• Rotate secrets after upgrading. Treat any admin API keys, user credentials, worker secrets, and cloud-provider keys as potentially compromised if the instance was exposed.
• Review logs for suspicious activity, especially calls to /v2/inference-backends/from-yaml and admin key creation from unexpected sources.
• If you cannot patch immediately, set force_auth_localhost to true and restrict API access to trusted networks. This reduces exposure but does not fully remove the risk, since proxy and header handling remains.

Keep an eye on breach reports and security news for updates on exploitation tied to this issue.

Security Insight

GPUStack’s localhost-trust model is a familiar trap: convenience for single-node deployments becomes an authentication bypass the moment the software is exposed behind a proxy or load balancer. The acceptance of a client-controlled X-GPUStack-Real-IP header is especially telling, since it let the client define its own trust level. For AI infrastructure tools that store cloud credentials and can run code, that shortcut carried outsized blast radius, and the in-the-wild 2.1.1 attack shows adversaries are already watching these emerging platforms closely.

Further Reading

• All Critical Vulnerabilities
• Recent Critical Vulnerabilities
• Top Critical CVEs