Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact An authenticated non-administrative user could access a Kubernetes cluster they are not authorized to access through GPUStack's Kubernetes API proxy. The `cluster_apiserver_proxy` handler did not perform a resource-level authorization check before forwarding requests to the selected cluster. Requests were forwarded through a worker using its Kubernetes ServiceAccount credentials. Depending on the permissions granted to that ServiceAccount, an attacker could read sensitive Kubernetes resources, create or modify workloads, or delete resources and disrupt services. Creating attacker-controlled workloads could result in code execution in the target cluster. Exploitation requires a Kubernetes-provider cluster with a reachable worker. The operations available to the attacker are limited by the worker's ServiceAccount permissions. Patches Fixed in `gpustack` `v2.2.2`. Workarounds Restrict access to the GPUStack instance to trusted administrator accounts until upgrading.
Recommended action: Upgrade to 2.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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…
Recommended action: Upgrade to 2.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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: 1. 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: ` — 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. Verified end-to-end against HEAD `6bee5883`. 2. `X-GPUStack-Real-IP` header. A forged `X-GPUStack-Real-IP: 127.0.0.1` header 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;…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.