GHSA-GJ9M-F8PH-PMHR
Vulnerability from github – Published: 2026-11-09 22:15 – Updated: 2026-11-09 22:15Impact
In GPUStack before v2.2.0, get_current_user (in gpustack/api/auth.py) promotes any request whose source is considered loopback to the built-in administrator account when force_auth_localhost is False (the default). The "source" is derived by client_ip_getter, which can be made to report 127.0.0.1 without any credentials in two ways:
- Same-host reverse proxy (TCP peer). In the canonical self-hosted shape —
GPUStack behind a same-host reverse proxy with
proxy_pass http://127.0.0.1:<port>— every remote request arrives at GPUStack with TCP peer127.0.0.1, so the loopback auto-admin branch fires. No header or credential is required. Verified end-to-end against HEAD6bee5883. X-GPUStack-Real-IPheader. A forgedX-GPUStack-Real-IP: 127.0.0.1header can cause the request source to be treated as loopback.
Either path yields full, unauthenticated administrative access over the network: enumerate and modify users, models, workers, and configuration; mint persistent admin API keys (scope ["*"], valid from any source IP thereafter); read worker credentials and cloud/provider secrets. Combined with admin-only functionality such as POST /v2/inference-backends/from yaml, this leads to code execution on worker hosts.
This vulnerability has been observed exploited in the wild against a v2.1.1 deployment (attacker-created custom backends running reverse shells).
Root cause
Trusting the network source of a request (socket peer, or a client-controllable header) as an authentication signal. When GPUStack is fronted by a same-host reverse proxy, the socket peer is always loopback, so the "localhost is trusted" assumption no longer holds.
Patches
Fixed in gpustack 2.2.0: the loopback auto-admin path was removed and client-IP / forwarding-header handling was hardened. Upgrade to 2.2.0 or later.
Workarounds
- Set
force_auth_localhost=trueto require authentication even for loopback requests. - Ensure the reverse proxy / gateway cannot cause GPUStack to treat external
traffic as loopback, and strip any client-supplied
X-GPUStack-Real-IPheader at the edge. - Keep the API off untrusted networks (VPN / edge authentication).
Remediation (in the fix)
Do not derive authentication from the request's network source. Remove implicit loopback-based admin, and only accept a real client-IP header from an authenticated/trusted gateway (never from arbitrary clients).
Credit
Independently reported by Nikko Enggaliano; Wei Yunzhou; and Rui Yang & Haoyu Wang (Johns Hopkins University). Active in the-wild exploitation was reported by Javier Sixto (ulex.fr).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gpustack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102895"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-09T22:15:27Z",
"nvd_published_at": "2026-11-04T22:17:44Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nIn GPUStack before v2.2.0, `get_current_user` (in `gpustack/api/auth.py`) promotes any request whose source is considered loopback to the built-in administrator account when `force_auth_localhost` is `False` (the default). The \"source\" is derived by `client_ip_getter`, which can be made to report `127.0.0.1` without any credentials in two ways:\n\n1. **Same-host reverse proxy (TCP peer).** In the canonical self-hosted shape \u2014\n GPUStack behind a same-host reverse proxy with `proxy_pass\n http://127.0.0.1:\u003cport\u003e` \u2014 every remote request arrives at GPUStack with TCP\n peer `127.0.0.1`, so the loopback auto-admin branch fires. No header or\n credential is required. Verified end-to-end against HEAD `6bee5883`.\n2. **`X-GPUStack-Real-IP` header.** A forged `X-GPUStack-Real-IP: 127.0.0.1`\n header can cause the request source to be treated as loopback.\n\nEither path yields **full, unauthenticated administrative access** over the network: enumerate and modify users, models, workers, and configuration; mint persistent admin API keys (scope `[\"*\"]`, valid from any source IP thereafter); read worker credentials and cloud/provider secrets. Combined with admin-only functionality such as `POST /v2/inference-backends/from yaml`, this leads to code execution on worker hosts.\n\nThis vulnerability has been observed exploited in the wild against a v2.1.1 deployment (attacker-created custom backends running reverse shells).\n\n### Root cause\n\nTrusting the network source of a request (socket peer, or a client-controllable header) as an authentication signal. When GPUStack is fronted by a same-host reverse proxy, the socket peer is always loopback, so the \"localhost is trusted\" assumption no longer holds.\n\n### Patches\n\nFixed in `gpustack` `2.2.0`: the loopback auto-admin path was removed and client-IP / forwarding-header handling was hardened. Upgrade to `2.2.0` or later.\n\n### Workarounds\n\n- Set `force_auth_localhost=true` to require authentication even for loopback\n requests.\n- Ensure the reverse proxy / gateway cannot cause GPUStack to treat external\n traffic as loopback, and strip any client-supplied `X-GPUStack-Real-IP`\n header at the edge.\n- Keep the API off untrusted networks (VPN / edge authentication).\n\n### Remediation (in the fix)\n\nDo not derive authentication from the request\u0027s network source. Remove implicit loopback-based admin, and only accept a real client-IP header from an authenticated/trusted gateway (never from arbitrary clients).\n\n### Credit\n\nIndependently reported by Nikko Enggaliano; Wei Yunzhou; and Rui Yang \u0026 Haoyu Wang (Johns Hopkins University). Active in the-wild exploitation was reported by Javier Sixto (ulex.fr).",
"id": "GHSA-gj9m-f8ph-pmhr",
"modified": "2026-11-09T22:15:27Z",
"published": "2026-11-09T22:15:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/security/advisories/GHSA-gj9m-f8ph-pmhr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102895"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/pull/5346"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/commit/53f42a6a553542974396d16a4ff6b12bcbedb48d"
},
{
"type": "PACKAGE",
"url": "https://github.com/gpustack/gpustack"
},
{
"type": "WEB",
"url": "https://github.com/gpustack/gpustack/releases/tag/v2.2.0"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-102895"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "GPUStack: Authentication bypass via trusted loopback source (reverse-proxy TCP peer or X-GPUStack-Real-IP header) grants unauthenticated admin"
}
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.