CVE-2026-102895: Active Exploit Against GPUStack, Total Admin Bypass

On November 12, 2025, the SANS Internet Storm Center confirmed active attacks against GPUStack, an open-source platform for managing GPU clusters used in AI workloads. The vulnerability CVE-2026-102895, rated CVSS 9.8, enables complete authentication bypass and unauthenticated administrative access. The bug was fixed in version 2.2.0 released in late June, but public disclosure in late July and CVE assignment on November 4 accelerated attacker adoption.

The Mechanism: When Loopback Becomes a Backdoor

The core of the vulnerability lies in GPUStack's get_current_user function, which treats any request identified as originating from the loopback address 127.0.0.1 as a trusted source. This logic, known as "localhost trust," automatically elevates such requests to the built-in administrator role without further authentication.

According to the GitHub Security Advisory, two vectors trigger this behavior. The first exploits an HTTP X-GPUStack-Real-IP header with the value 127.0.0.1: the server interprets the header as an indication of the true source and applies the auto-admin privilege. The second vector requires no manipulated header: when GPUStack sits behind a reverse proxy on the same host, every remote request arrives at the service with a TCP peer address of 127.0.0.1, automatically triggering the privileged authentication branch.

This second condition is particularly relevant for containerized and Kubernetes deployments, where sidecar proxies or ingress controllers on the same node are a common configuration. The advisory confirms end-to-end verification of this scenario.

The Impact: Total Control of the AI Cluster

"Either path yields full, unauthenticated administrative access over the network: enumerate and modify users, models, workers, and configuration; mint persistent admin API keys" — GitHub Security Advisory GHSA-gj9m-f8ph-pmhr

Compromise of a GPUStack node exposes critical AI infrastructure functionality. The attacker gains the ability to enumerate and modify users, loaded models, cluster workers, and system configuration. The creation of persistent administrative API keys ensures continued access even after partial remediation.

The advisory also documents the reading of worker credentials and secrets related to cloud providers, though it does not specify the exact nature of these secrets. Complete cluster takeover enables follow-on operations: according to the same source, confirmed in-the-wild attacks have installed custom backends with reverse shells.

The Field: Active Exploits from IP 144.91.73.103

Confirmation of active exploitation is not theoretical. Johannes B. Ullrich of the SANS Internet Storm Center reported exploit requests originating from IP 144.91.73.103, leveraging the X-GPUStack-Real-IP header:

"If the 'X-Gpustack-Real-IP' identifies loopback (127.0.0.1) as the source of the request, Gpustack bypasses authentication (after all, the request originates from a trusted source)" — Johannes B. Ullrich, SANS.edu

The GitHub advisory independently confirms in-the-wild exploitation against a specific GPUStack v2.1.1 installation, with evidence of malicious backends and reverse shells. The convergence of the two sources — the SANS network indicator and the vendor advisory's technical description — makes the threat immediate and verified, not hypothetical.

No infrastructure overlaps linking the actor behind IP 144.91.73.103 to known campaigns emerge in the dossier at this time. The full extent of the exploit campaign remains unquantified: the dossier mentions a single IP address, without ruling out the presence of other actors or infrastructure.

Immediate Actions

Priority actions derive directly from verified sources:

• Update to GPUStack 2.2.0: The late June release removes the loopback auto-admin behavior and hardens client address handling.
• Set force_auth_localhost=true: The configuration parameter, indicated by the advisory as a workaround, disables the authentication bypass for local requests.
• Filter the X-GPUStack-Real-IP header: Remove or strip the header at the reverse proxy or WAF level to prevent source spoofing.
• Verify for anomalous administrative access: Check existing sessions, created API keys, and loaded backends in environments running versions prior to 2.2.0.

"Localhost Trust" as a Recurring Failure

Authentication logic based on source address is not new: treating 127.0.0.1 as an implicitly trusted entity has generated similar vulnerabilities in protocols and applications for decades. What makes CVE-2026-102895 significant is the deployment context. AI infrastructure platforms like GPUStack are high-value targets: they manage expensive GPU resources, proprietary models, and access to cloud provider credentials. Containerization and the pervasive use of sidecar proxies amplify the likelihood that the "same-host reverse proxy" condition — the second, headerless vector — is active in production without operators' awareness.

The research leading to discovery was conducted independently by four researchers: Nikko Enggaliano, Wei Yunzhou, Rui Yang, and Haoyu Wang of Johns Hopkins University. Their disclosure produced an advisory with complete technical details and end-to-end verification, a level of documentation that enabled timely SANS ISC analysis as soon as exploitation became active in the field.

Frequently Asked Questions

Does updating to 2.2.0 require changes to existing configuration?

The fix modifies the default behavior by removing loopback auto-admin. Operators who relied on this functionality for local access must evaluate the impact on their workflow and plan the transition.

Is the same-host reverse proxy vector more dangerous than header spoofing?

The proxy vector is more insidious because it requires no knowledge of the specific header: any deployment with a reverse proxy on the same node is vulnerable without attacker action on the request, if the network configuration produces a TCP peer of 127.0.0.1.

Is IP 144.91.73.103 still active?

The dossier contains no information on the temporal persistence of activity from that address. The recommendation to update remains valid regardless of the current status of specific indicators.

Sources

• isc.sans.edu
• github.com