CVE-2026-102895 in GPUStack
Summary
by MITRE • 11/05/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
GPUStack serves as an open-source solution for managing GPU clusters, specifically designed to facilitate AI model serving and the provisioning of GPU instances. In versions prior to 2.2.0, a critical authentication bypass vulnerability exists within the API authorization logic located in gpustack/api/auth.py. The core technical flaw stems from how the get_current_user function handles requests originating from loopback addresses when the configuration parameter force_auth_localhost is set to false, which is the default setting for most deployments. Under these conditions, any request arriving at a local interface such as 127.0.0.1 or ::1 was automatically authenticated as the built-in administrator without requiring valid credentials. This design decision creates a significant security gap because it assumes that traffic on loopback interfaces is inherently trustworthy and originates from trusted internal processes rather than external actors who can manipulate network routing or proxy configurations to spoof local addresses.
The vulnerability is exacerbated by the behavior of the client_ip_getter function, which determines the source IP address for authentication decisions. This function accepts two specific inputs that allow remote attackers to bypass security controls: it trusts the peer address if a same-host reverse proxy is in use, and it also respects a custom header named X-GPUStack-Real-IP provided by the client. Consequently, an attacker located on a different network can send HTTP requests with the source IP spoofed or proxied through a local interface, or simply include the X-GPUStack-Real-IP header set to 127.0.0.1. By doing so, the application incorrectly identifies these remote requests as local administrative traffic, granting them full administrator privileges without any form of authentication. This mechanism effectively neutralizes network perimeter defenses and allows unauthenticated access from potentially distant locations if routing or proxy configurations permit such IP manipulation.
The operational impact of this vulnerability is severe due to the high level of privilege granted by the bypassed authentication. Once an attacker gains administrative access, they can perform a wide range of malicious actions that compromise the integrity, confidentiality, and availability of the GPU cluster environment. These actions include modifying user accounts and configurations, altering AI model deployments, and creating persistent administrator API keys that ensure long-term unauthorized access even if other security measures are tightened. Furthermore, attackers can exfiltrate sensitive worker credentials and cloud-provider secrets stored within the system configuration, leading to potential lateral movement or financial loss through compromised cloud infrastructure. Most critically, the vulnerability allows for remote code execution via POST requests to /v2/inference-backends/from-yaml, enabling attackers to execute arbitrary commands on the underlying host systems with the privileges of the GPUStack service process.
This flaw is classified under CWE-287 as an Improper Authentication issue and aligns with MITRE ATT&CK techniques related to Initial Access via Valid Accounts and Privilege Escalation through authentication bypass mechanisms. The severity of this vulnerability has been confirmed by real-world exploitation, with observed attacks targeting deployments running version 2.1.1. These incidents highlight the practical risk posed by misconfigured or default settings in container orchestration tools that handle sensitive infrastructure components. To mitigate this issue, organizations must upgrade to GPUStack version 2.2.0 immediately, where the authentication logic has been corrected to properly validate source addresses and reject spoofed loopback requests from remote sources. Additionally, administrators should review their network configurations to ensure that reverse proxies do not inadvertently expose internal services to untrusted networks and consider enforcing strict IP whitelisting for administrative endpoints as a defense-in-depth measure.