GPUStack Flaws Break Two Different Trust Boundaries

GPUStack SAML and cluster takeover flaws break two separate controls. CVE-2026-102894 lets a network client cross the identity boundary, while CVE-2026-103002 lets an authenticated non-administrator cross a Kubernetes authorization boundary.

Both flaws are fixed in GPUStack 2.2.2. The first affects versions from 0.7.1 before 2.2.2, while the second affects versions from 2.2.0 before 2.2.2.

This distinction matters during triage. A deployment can be exposed to the SAML flaw even when SAML is not configured, but the cluster flaw has narrower infrastructure requirements.

GPUStack SAML and Cluster Takeover Flaws Cross Different Boundaries

CVE-2026-102894 sits at the authentication boundary. GPUStack decoded identity data and used its contents before completing the cryptographic and protocol checks expected for a SAML response.

The advisory says the callback did not verify the signature, issuer, audience, destination, or time conditions. It could then resolve an existing user or provision a new non-administrator account and issue a session.

An identity matching an existing administrator could therefore receive that administrator’s session. The advisory also says captured signed responses could be replayed because response and assertion identifiers were not consumed.

The critical point is configuration independence. The vulnerable route processed supplied identity data even when SAML was not the configured authentication provider.

CVE-2026-103002 begins after authentication. Its issue was a missing resource-level authorization check in the proxy that forwarded requests toward a selected Kubernetes cluster.

The proxy used a reachable worker’s Kubernetes ServiceAccount credentials. Consequently, the worker account’s permissions, rather than the GPUStack user’s intended authorization, governed the forwarded operation.

The consequences can overlap, but the bugs are not one combined exploit. An administrator session grants broad GPUStack control, while cluster impact depends on the selected worker’s ServiceAccount permissions.

How Do the Trust Failures Unfold?

The first path accepts identity data before proving who signed it and where it was intended to be used. The second path accepts an authenticated identity but fails to enforce whether that identity may reach the selected cluster resource.

1. 1Network client GPUStack identity layerSupplies identity data to an affected callback
2. 2GPUStack identity layer to itselfResolves or provisions a user before required SAML validation
3. 3GPUStack proxy Kubernetes workerForwards without the required resource-level authorization check

The diagram shows two advisory-described paths, not a required chained attack. CVE-2026-103002 only requires an authenticated non-administrator, so that identity may come from ordinary account access.

For CVE-2026-102894, the missing validation covered more than a signature check. Issuer, audience, destination, and time conditions are all boundaries that bind an assertion to the correct identity provider, service, route, and validity period.

The fix now processes the response through the SAML validation library and rejects failures. GPUStack also gates SAML and OIDC login routes so only the configured active provider can use them.

For CVE-2026-103002, the affected proxy transferred the request into a second authorization domain. Once there, Kubernetes enforced what the worker ServiceAccount could do, not what the initiating GPUStack user should do.

The advisory lists sensitive resource reads, workload creation or modification, and resource deletion as possible outcomes. Attacker-controlled workloads could produce code execution in the target cluster.

Those outcomes are conditional. Exploitation requires a Kubernetes-provider cluster, a reachable worker, and sufficient permissions on the worker’s ServiceAccount.

Which GPUStack Deployments Need Priority?

Every reachable GPUStack deployment from version 0.7.1 before 2.2.2 belongs in the SAML review. Administrators should not remove systems from scope merely because SAML is disabled or absent.

The cluster authorization review starts at version 2.2.0 before 2.2.2. It then narrows to Kubernetes-provider clusters with workers that the GPUStack proxy can reach.

Prioritize systems exposed beyond a tightly controlled management network. Within the Kubernetes subset, prioritize workers whose ServiceAccounts can read secrets, modify workloads, or delete operational resources.

Brandefense Blackhole recorded three dark-chat references to CVE-2026-102894 and two Telegram posts referencing CVE-2026-103002 from August 12 through November 10, 2026. These counts show attention around the identifiers, not successful exploitation.

The advisories assign CVSS 3.1 scores of 9.1 to CVE-2026-102894 and 8.8 to CVE-2026-103002. The records provide no CVSS 4.0 score.

What Can Defenders Verify Without Reproducing the Flaws?

Start with version and topology evidence. Inventory GPUStack versions, external and internal reachability, configured identity providers, Kubernetes-provider clusters, reachable workers, and worker ServiceAccount permissions.

For the identity flaw, review authentication records for unexpected session creation, administrator access, and accounts provisioned through the identity flow. Correlate those events with the expected identity-provider records and approved login periods.

Do not assume an event is legitimate because it carries a familiar username. The vulnerable behavior trusted identity attributes before validating the response that supplied them.

For the cluster flaw, compare GPUStack user authorization with Kubernetes audit activity performed through worker ServiceAccounts. Focus on sensitive reads, workload changes, and deletions that lack an approved administrative change.

Also review whether worker ServiceAccounts hold permissions beyond their operational need. Reduced permissions can limit impact, but least privilege is not a substitute for installing the fixed GPUStack release.

Teams can place these checks inside an established vulnerability management process. Track the two CVEs separately so their different exposure conditions remain visible.

Upgrade and Contain GPUStack in This Order

• Inventory affected versionsFind GPUStack releases below 2.2.2 and record their network reachability and provider type.
• Upgrade to 2.2.2Deploy the vendor’s fixed version across management nodes before treating configuration changes as sufficient.
• Restrict temporary accessUntil the upgrade is complete, block network access to the affected SAML callback and limit GPUStack access to trusted administrators.
• Validate identity activityReview session creation, administrator access, and newly provisioned accounts against identity-provider evidence.
• Validate cluster activityCompare GPUStack authorization with Kubernetes audit events performed through worker ServiceAccounts.
• Reduce service account scopeRemove unnecessary worker permissions and document the access each GPUStack operation requires.
• Verify the running releaseConfirm every node uses 2.2.2 and record exceptions with an owner and deadline.

The SAML advisory says there is no effective configuration-level workaround on affected versions. Not configuring SAML does not prevent the vulnerable callback from processing supplied data.

Its temporary measure is to block network access to that callback at the ingress or reverse proxy. The cluster advisory recommends restricting GPUStack access to trusted administrator accounts until upgrading.

Use a controlled patch management process to confirm the active release, not only package deployment. Then retain authentication and Kubernetes audit evidence for follow-up.

If review finds unexplained administrator sessions or cluster changes, move the case into an incident response plan. Preserve relevant records before rotating credentials or rebuilding affected workloads.

GPUStack 2.2.2 closes both reported paths, but remediation evidence differs. Identity validation must be proven at the application boundary, while cluster authorization must be checked against Kubernetes activity and ServiceAccount scope.