GPUStack CVE-2026-102894: SAML Callback Forges Sessions Without Signature Checks

GitHub reviewed GHSA-62m9-f875-rqw6 (CVE-2026-102894) on November 10, 2026: GPUStack before 2.2.2 trusts attacker-crafted SAMLResponse XML at /auth/saml/callback and mints a gpustack_session JWT without cryptographic verification. No password, no configured IdP, and no enabled SAML SSO are required—the callback runs anyway. If you self-host GPUStack for OpenAI-compatible inference used by coding agents, upgrade to 2.2.2+, block /auth/saml/callback at your ingress until patched, and audit admin sessions and API keys if the API was reachable from untrusted networks.

This is a second critical auth flaw in the same product family as CVE-2026-102895 (loopback admin promotion, CISA KEV, fixed in 2.2.0). Patching only to 2.2.0 closes the KEV issue but not this SAML callback gap.

TL;DR

What the advisory documents

The GitHub Advisory Database entry and matching NVD record for CVE-2026-102894 describe the failure as improper verification of cryptographic signatures (CWE-347) combined with authentication bypass by capture-replay (CWE-294).

Impact path. The callback Base64-decodes posted XML, reads NameID and attributes, resolves or provisions a user, and issues a gpustack_session JWT. It never calls OneLogin_Saml2_Auth.process_response(), the step that validates signature, issuer, audience, destination, and time conditions.

Preconditions. Network reachability to /auth/saml/callback. SAML SSO configuration is not required; the handler processes payloads even when SAML is not the active login method.

Attacker outcomes.

1. If the forged identity matches an existing user (for example an administrator), the attacker receives that user's session—full account takeover.
2. Otherwise GPUStack creates a new non-admin user and still issues a session.
3. Administrator access implies full control over the deployment and the GPU infrastructure it manages—the same class of risk described for other GPUStack admin compromises in our KEV write-up.
4. Because Response/Assertion IDs are never consumed, a captured signed response can replay indefinitely once an attacker obtains one.

Affected and patched versions (per the advisory): affected >= 0.7.1, < 2.2.2; patched 2.2.2, with fixes in gpustack/gpustack#5753, gpustack/gpustack#5923, and release v2.2.2.

Workarounds. The vendor states there is no effective configuration-level workaround: disabling or not configuring SAML does not mitigate on affected versions. Until upgrade, block network access to /auth/saml/callback (for example at a reverse proxy or ingress).

Credit: Austin Chu, Sohee Kim, and Corban Villa (UC Berkeley security research project), and an earlier anonymous reporter.

Attack chain, step by step

This sequence follows the public advisory text; we did not run a private proof of concept.

1. Discover a reachable GPUStack HTTP endpoint exposing /auth/saml/callback (common on default installs behind nginx or a cloud load balancer).
2. Craft or replay SAMLResponse XML naming a target identity (for example the built-in admin username your org uses).
3. POST the Base64 payload to the callback route. The server decodes XML without signature verification.
4. Receive a valid gpustack_session JWT bound to the resolved or newly provisioned user.
5. Use admin APIs to read secrets, reconfigure workers, mint long-lived API keys, or alter inference backends—parallel to post-exploitation paths documented for CVE-2026-102895.

The distinguishing feature versus the loopback flaw is forged identity via SAML-shaped XML rather than spoofed client IP. Both issues are unauthenticated network attack vectors against the control plane, not the model inference path alone.

How this differs from CVE-2026-102895 (loopback admin)

Both bugs hand an attacker administrator-equivalent control plane access, but the entry points and mitigations diverge. Patching culture on self-hosted inference stacks often stops at the first critical advisory—here that leaves a second hole open.

Teams that remediated only the KEV item should treat 2.2.2 as the minimum safe floor, not 2.2.0.

Timeline and disclosure notes

Understanding when each flaw became public helps prioritize log review windows:

• CVE-2026-102894 was published to the GitHub Advisory Database on November 10, 2026, with GitHub's reviewed flag set the same day.
• The National Vulnerability Database associated CVE-2026-102894 on November 4, 2026, earlier than the GitHub reviewed stamp—version and severity text should still be taken from the GitHub advisory and release v2.2.2.
• CVE-2026-102895 entered CISA KEV on November 9, 2026 with vendor-confirmed exploitation on 2.1.1—a useful reminder that two critical auth issues shipped in the same product line within weeks.

Neither advisory claims a separate in-the-wild exploitation count for the SAML flaw in the public text we fetched. That does not reduce urgency on internet-exposed panels: both issues are unauthenticated, network-reachable, and admin-impact.

Forensics: what to look for after exposure

If your GPUStack API was reachable from untrusted networks on versions before 2.2.2, review evidence before you declare the host clean:

1. HTTP access logs for POST /auth/saml/callback from non-corporate IP ranges, especially before your upgrade timestamp. Unexpected volume or 200 responses without legitimate IdP maintenance windows are worth escalation.
2. Session and user tables for accounts created or promoted around the same timestamps—remember the advisory allows provisioning new users or matching existing admin NameIDs.
3. API key inventory for keys with admin scope created after your last known-good backup. Compare to change tickets; rotate any unexplained key agents or CI still reference.
4. Inference backend definitions, particularly YAML-imported backends—attackers who reach admin through either CVE class may add worker code similar to paths described in the 102895 advisory.
5. Downstream abuse on OpenAI-compatible endpoints: spike in token usage, novel model names, or worker egress to unfamiliar subnets after a suspected compromise window.

Document findings even if you find nothing; negative evidence helps close tickets when auditors ask whether coding-agent keys could have been copied from the control plane.

What changed in GPUStack 2.2.2

Per the advisory, 2.2.2 does two things:

1. Validates SAML responses through OneLogin_Saml2_Auth.process_response(), rejecting forged or replayed assertions that fail checks.
2. Gates SAML and OIDC login/callback routes so they run only when that provider is the configured active provider, so deployments without SAML enabled no longer parse attacker-supplied IdP payloads on those routes.

Confirm the running build: pip show gpustack in the service virtualenv, or your container image digest against v2.2.2 release assets.

Who is affected

In scope: Any team running self-hosted GPUStack for local or lab inference that coding tools reach through OpenAI-compatible base URLs—including setups beside Xinference on rented GPU hosts, CI evaluation clusters, or internal model routers.

Higher risk: Internet-exposed admin UIs without edge authentication, or nginx paths that forward /auth/* to GPUStack without path-based restrictions.

Not a client-side patch: Developer laptops running Claude Code or Codex do not embed GPUStack; the risk is server-side compromise and downstream secret theft (API keys agents store in env files, MCP configs, or CI variables).

What this means if you run AI coding agents

Agents rarely post SAML XML themselves, but they depend on the integrity of inference endpoints:

1. Version check today. pip show gpustack (or your Helm chart appVersion). If the result is below 2.2.2, plan an emergency upgrade even if you already applied 2.2.0 for the KEV loopback issue.
2. Ingress rule. Until patched, deny /auth/saml/callback from all non-administrative networks at the proxy—treat this like blocking an unauthenticated admin API.
3. Rotate inference credentials if the GPUStack API was reachable from the internet on a vulnerable version during the advisory window (published to GitHub Advisory Database November 10, 2026; NVD association November 4, 2026).
4. Review agent configs for OPENAI_BASE_URL, LiteLLM routes, or MCP server entries pointing at your GPUStack host. After admin takeover, attackers may have copied keys agents use for automated commits or evaluations—see LLMjacking guidance for log patterns on abused keys.
5. Do not trust “SAML disabled” on < 2.2.2 builds; the advisory explicitly states the callback still runs.

If you also run Kubeflow Pipelines or other GPU-adjacent stacks agents trigger from notebooks, keep control-plane patches separate from model-container updates—agents will not remind you which middleware version is live.

LiteLLM and proxy layers deserve a second pass: many teams point agents at http://gpustack.internal/v1 through a proxy that also terminates TLS. A compromised control plane can swap model routes or embeddings targets without touching laptop configs until the next agent restart—reconcile proxy config git history with GPUStack audit timelines.

Supply-chain parallels: November's cluster of GPUStack, Kubeflow upload, and FastAPI generator issues share a pattern: middleware that agents treat as infrastructure wallpaper gets fewer human eyes than application code. Add pip show gpustack (or image digest checks) to the same checklist you use for npm audit before agent-heavy sprints.

What Beam can and cannot do here

Beam does not terminate SAML, inspect GPUStack HTTP traffic, or patch inference managers. It is local, on-device observability for Claude Code, Codex, and similar harnesses on developer machines.

Where overlap exists: if compromise leads to API keys written into repos, MCP configs repointed at hostile hosts, or destructive shell commands during incident cleanup, Beam's heuristic skill and MCP config scanning and PreToolUse hook denies (where configured) can surface risky follow-on actions before they persist locally. That is a secondary control—not a substitute for 2.2.2 or ingress blocking. Scanning is heuristic, not malware analysis; enforce modes can be fail-open without cached policy.

See how Beam watches agent activity and the November 2026 attacks timeline for related incidents this month.

Related reading

• GPUStack CVE-2026-102895 CISA KEV loopback bypass
• Fireworks AI breach and LLMjacking economics for agent keys
• Kubeflow Pipelines CVE-2026-77596 shared upload gap
• IBM Aspera Faspex CISA KEV admin bypass pattern
• Hugging Face miner campaign on GPU hosts

Frequently asked questions

What is GPUStack CVE-2026-102894?

It is a critical authentication bypass in GPUStack before 2.2.2. The /auth/saml/callback handler decodes attacker-supplied SAMLResponse XML and issues a gpustack_session JWT without verifying signatures, issuer, audience, or time conditions via OneLogin_Saml2_Auth.process_response().

Does disabling SAML protect my GPUStack server?

No. The advisory states SAML SSO does not need to be configured—the callback still parses posted XML and mints sessions on affected versions. Blocking network access to /auth/saml/callback is the only configuration-level mitigation until you upgrade.

I upgraded to 2.2.0 for CVE-2026-102895. Am I safe from CVE-2026-102894?

Not necessarily. The loopback admin bypass fixed in 2.2.0 is a different CVE. GHSA-62m9-f875-rqw6 requires 2.2.2. Any release from 0.7.1 up to but not including 2.2.2 carries the SAML flaw.

What can an attacker do after forging a session?

If the forged NameID matches an existing user—including an administrator—the attacker receives that account's session. Administrator sessions grant full control over models, workers, secrets, and GPU infrastructure the manager orchestrates.

How do I check my installed version?

Run pip show gpustack in the environment that runs the server, or check your container image tag against GPUStack v2.2.2.

Can coding agents trigger this vulnerability?

Agents do not exploit SAML directly, but they often store OpenAI-compatible base URLs and API keys for self-hosted stacks. An attacker who forges an admin session can read or rotate those secrets—rotate keys if your control plane was internet-exposed on a vulnerable build.

Advisory text, version numbers, and CVSS fields reflect public GitHub and NVD sources as of November 10, 2026. Confirm the running build on each host before closing an incident.