GHSA-62M9-F875-RQW6
Vulnerability from github – Published: 2026-11-10 15:57 – Updated: 2026-11-10 15:57Impact
The callback Base64-decodes the posted XML, reads NameID and attributes, resolves or provisions the user, and mints a gpustack_session JWT — but never calls OneLogin_Saml2_Auth.process_response(), the step that verifies the signature, issuer, audience, destination, and time conditions.
No credentials are required, and SAML SSO does not even need to be configured. The callback processes the payload and issues a session regardless of whether SAML is set up, so every deployment is affected, not only SAML-enabled ones. Anyone who can reach the endpoint over the network can authenticate as an arbitrary identity by posting a response that names it:
- If the name matches an existing user (e.g. an administrator), the attacker receives that user's session — full account takeover, including administrator access.
- Otherwise, a new non-admin user is provisioned.
Administrator access grants full control over the deployment and the infrastructure it manages. Because Response/Assertion IDs are never consumed, a captured signed response also replays indefinitely.
Precondition: network reachability to /auth/saml/callback. SAML SSO configuration is not required. A full proof-of-concept is available privately to maintainers.
Patches
Fixed in gpustack 2.2.2: - The SAML callback now validates the response via OneLogin_Saml2_Auth.process_response() — signature, issuer, audience, destination, and time conditions — and rejects responses that fail, so forged or replayed assertions are no longer accepted. - The SAML and OIDC login/callback routes are now gated to run only when that provider is the configured active provider, so a deployment that has not enabled the provider no longer parses attacker-supplied IdP payloads.
Workarounds
There is no effective configuration-level workaround — disabling or not configuring SAML does not mitigate this on affected versions, since the callback runs regardless. Until upgraded, block network access to /auth/saml/callback (e.g. at a reverse proxy / ingress).
Credit
Reported privately by Austin Chu, Sohee Kim, and Corban Villa (UC Berkeley security research project), and independently, earlier, by a researcher who wishes to remain anonymous.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gpustack"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.1"
},
{
"fixed": "2.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102894"
],
"database_specific": {
"cwe_ids": [
"CWE-294",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-10T15:57:15Z",
"nvd_published_at": "2026-11-04T22:17:44Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThe callback Base64-decodes the posted XML, reads NameID and attributes, resolves or provisions the user, and mints a gpustack_session JWT \u2014 but never calls OneLogin_Saml2_Auth.process_response(), the step that verifies the signature, issuer, audience, destination, and time conditions.\n\nNo credentials are required, and SAML SSO does not even need to be configured. The callback processes the payload and issues a session regardless of whether SAML is set up, so every deployment is affected, not only SAML-enabled ones. Anyone who can reach the endpoint over the network can authenticate as an arbitrary identity by posting a response that names it:\n\n- If the name matches an existing user (e.g. an administrator), the attacker receives that user\u0027s session \u2014 full account takeover, including administrator access.\n- Otherwise, a new non-admin user is provisioned.\n\nAdministrator access grants full control over the deployment and the infrastructure it manages. Because Response/Assertion IDs are never consumed, a captured signed response also replays indefinitely.\n\nPrecondition: network reachability to /auth/saml/callback. SAML SSO configuration is not required. A full proof-of-concept is available privately to maintainers.\n\n\n### Patches\n\nFixed in gpustack 2.2.2:\n- The SAML callback now validates the response via OneLogin_Saml2_Auth.process_response() \u2014 signature, issuer, audience, destination, and time conditions \u2014 and rejects responses that fail, so forged or replayed assertions are no longer accepted.\n- The SAML and OIDC login/callback routes are now gated to run only when that provider is the configured active provider, so a deployment that has not enabled the provider no longer parses attacker-supplied IdP payloads.\n\n### Workarounds\n\nThere is no effective configuration-level workaround \u2014 disabling or not configuring SAML does not mitigate this on affected versions, since the callback runs regardless. Until upgraded, block network access to /auth/saml/callback (e.g. at a reverse proxy / ingress).\n\n### Credit\n\nReported privately by Austin Chu, Sohee Kim, and Corban Villa (UC Berkeley\nsecurity research project), and independently, earlier, by a researcher who wishes to remain anonymous.",
"id": "GHSA-62m9-f875-rqw6",
"modified": "2026-11-10T15:57:15Z",
"published": "2026-11-10T15:57:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/security/advisories/GHSA-62m9-f875-rqw6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102894"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/pull/5753"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/pull/5923"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/commit/705edbe1b5feec63959306daecd640e1c70eced2"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/commit/adc6d82be34e48390720a1361df616e2ea9d6d45"
},
{
"type": "PACKAGE",
"url": "https://github.com/gpustack/gpustack"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/releases/tag/v2.2.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "GPUStack: SAML callback trusts an unverified SAMLResponse, allowing authentication bypass and account takeover"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.