CVE-2026-102895

What's affected. GPUStack before 2.2.0, per GitHub advisory GHSA-gj9m-f8ph-pmhr and NVD. A server is reachable if it runs a version below 2.2.0, force_auth_localhost is false (the default before 2.2.0), and an attacker can reach it over the network.

How it works. Before 2.2.0, GPUStack treated any request it believed came from the server itself (loopback, 127.0.0.1) as the built-in administrator. The advisory gives two ways to make a remote request look like that.

1. Check for a same-host reverse proxy. This is the common case. Per the advisory, when GPUStack sits "behind a same-host reverse proxy with proxy_pass http://127.0.0.1:<port>," "every remote request arrives at GPUStack with TCP peer 127.0.0.1, so the loopback auto-admin branch fires. No header or credential is required." Look at the nginx, Caddy or other proxy config on the GPUStack host for a backend of 127.0.0.1 or localhost. If you find one and you are below 2.2.0, treat every request through that proxy as admin.
2. Check whether your edge strips the X-GPUStack-Real-IP header. The advisory says "A forged X-GPUStack-Real-IP: 127.0.0.1 header can cause the request source to be treated as loopback." If your edge passes this header through from clients, any request can claim to be loopback.
3. Check the force_auth_localhost setting. Both paths work only when force_auth_localhost is false, which the advisory calls the default. Look for --force-auth-localhost or force_auth_localhost in your start flags or config. GPUStack's current docs list the flag as "(Deprecated, no-op) Localhost callers are always authenticated," which describes the fixed versions, not older ones.
4. Check the version. Anything below 2.2.0 is affected.

What an attacker gets. Per the advisory, admin access lets an attacker change users, models, workers and configuration, "mint persistent admin API keys (scope ["*"], valid from any source IP thereafter)," "read worker credentials and cloud/provider secrets," and, through POST /v2/inference-backends/from-yaml, run code on worker hosts.

Companion: CVE-2026-102894 (SAML). GitHub, as CNA, scores it 9.1. Per NVD, from 0.7.1 until 2.2.2 the /auth/saml/callback endpoint created a session "without calling OneLogin_Saml2_Auth.process_response to verify the signature," so "Any network client could submit an identity for an existing user, including an administrator ... even when SAML was not configured." It is fixed in 2.2.2, so upgrading only to 2.2.0 leaves it open.

Exploitation, as reported. GPUStack's advisory says "This vulnerability has been observed exploited in the wild against a v2.1.1 deployment (attacker-created custom backends running reverse shells)." It credits Javier Sixto (ulex.fr) with reporting the exploitation. It is not on CISA KEV.

These come from GPUStack's advisory. Each works only under the condition at the end of its line.

• Delivery. "Keep the API off untrusted networks (VPN / edge authentication)." This only helps if no untrusted client can reach the proxy or the GPUStack port.
• Exploitation. "Set force_auth_localhost=true to require authentication even for loopback requests." This only helps if you confirm the setting took effect on your running version, and it does nothing for CVE-2026-102894.
• Exploitation. "Ensure the reverse proxy / gateway cannot cause GPUStack to treat external traffic as loopback, and strip any client-supplied X-GPUStack-Real-IP header at the edge." This only helps if you do both, since stripping the header alone does not close the same-host proxy path.

Upgrading to 2.2.2 is the only fix for both CVEs.

GPUStack's advisory publishes no indicators or compromise checks. The reported attack used "attacker-created custom backends running reverse shells."

If you patched late. Patching does not remove access an attacker already has, and the advisory says admin API keys created through the bug stay "valid from any source IP thereafter." Our reading (Tuskira), not vendor guidance: review inference backends, users and API keys you did not create, and rotate worker and cloud-provider credentials.

Am I exposed to CVE-2026-102895?

Yes, if you run GPUStack below 2.2.0 with force_auth_localhost false (the default) and an attacker can reach it, most often through a reverse proxy on the same host.

Is CVE-2026-102895 being exploited?

GPUStack's advisory says it "has been observed exploited in the wild against a v2.1.1 deployment." It is not on CISA KEV as of November 5, 2026.

Do I need to log in or send a special header to exploit it?

No. Behind a same-host reverse proxy, the advisory says "No header or credential is required." The forged header is a second way in.

Which version fixes it?

2.2.0 fixes CVE-2026-102895. 2.2.2 also fixes the SAML bypass CVE-2026-102894, so upgrade to 2.2.2.

How do I mitigate CVE-2026-102895 without patching?

Keep GPUStack off untrusted networks, set force_auth_localhost=true, and make sure your proxy can't make outside traffic look local, per GPUStack. These reduce exposure but are not a fix.

Nov 5, 2026. First published. GPUStack reports exploitation in the wild; not on CISA KEV.

• GPUStack advisory GHSA-gj9m-f8ph-pmhr (published July 31, 2026)
• NIST NVD: CVE-2026-102895 and CVE-2026-102894 (GitHub's CNA records; checked Nov 5)
• GPUStack 2.2.0 release (June 18, 2026) and 2.2.2 release (July 24, 2026)
• GPUStack CLI reference, gpustack start
• CISA Known Exploited Vulnerabilities catalog (checked Nov 5)