CVE-2026-58658 (CVSS 3.1: 8.2 / CVSS 4.0: 8.8, High) is an unauthenticated information-disclosure vulnerability in GPUStack, an open-source GPU cluster manager used to orchestrate vLLM, SGLang, and TensorRT-LLM inference across on-prem servers, Kubernetes clusters, and cloud GPU fleets. Every GPUStack worker through version 2.2.1 exposed a set of debug and log-streaming HTTP endpoints with no authentication check at all, letting anyone who could reach the worker port pull live model inference logs — including the raw prompts and completions passing through the cluster — without a credential.

What happened

GPUStack splits into a server component and one or more worker processes, each running on a machine with GPUs attached. Workers run their own HTTP API on port 10150 (bound to 0.0.0.0 by default) so the server can proxy requests to them — health checks, filesystem access, log retrieval, debug controls. Most of those worker routes already required a bearer token issued by the server. The debug and logs routers didn’t.

Two route groups shipped with no Depends(worker_request_auth) dependency, unlike every other sensitive worker router:

  • /debug — lets a caller change the worker’s log level and pull memory-profiling data at will.
  • /serveLogs, /serveLogOptions, /benchmark_logs — stream serving logs for a given model instance, including prompts and completions sent through that instance, and expose benchmark run output.

Because model instance IDs are small, easily enumerable integers, an attacker didn’t even need internal knowledge of the deployment to pull data: sweep IDs against /serveLogs on the worker port and harvest whatever is currently being served. Cranking the log level up via /debug before hitting /serveLogs increases the volume of captured data further. None of this requires a GPUStack account, an API key, or network position beyond reaching the worker’s listening port.

Affected versions and fix

GPUStack versions through 2.2.1 are affected. The fix landed in commit 4e20551, which adds the same worker_request_auth dependency already used by the filesystem, proxy, and cluster-proxy routers to both the debug and logs routers. Health-check and version endpoints remain intentionally public; everything that returns log content or lets a caller mutate worker state now requires the bearer token the GPUStack server already sends on every proxied request — the fix is transparent to legitimate server-to-worker traffic. Operators should upgrade to the patched release rather than backport the single commit, since worker/server protocol versions are expected to match.

Impact

The blast radius scales with how exposed the worker port is. GPUStack is commonly deployed with workers spread across a Kubernetes cluster or a flat internal network, and the worker API binding to 0.0.0.0 by default means any workload or host on the same network segment — a compromised neighboring pod, a misconfigured security group, a flat VPC — gets unauthenticated read access to whatever is running through that GPU node. For LLM serving specifically, that means:

  • Prompt/completion leakage — anything sent to a model hosted on the affected worker, potentially including customer data, internal documents, or proprietary prompts, is readable by anyone on the network path.
  • Reconnaissance for further attack — memory profiling data and log output can reveal model names, configuration, and internal topology useful for planning a deeper compromise.
  • Log-level manipulation — an attacker can crank verbosity up to capture more data than the operator intended to log in the first place, effectively weaponizing the worker’s own instrumentation against it.

There’s no indication this was exploited before disclosure; it was reported and fixed through normal coordinated disclosure. But GPU inference clusters are exactly the kind of infrastructure that tends to sit inside a “trusted” internal network with looser east-west controls than internet-facing services, which is precisely the assumption this bug breaks.

Mitigation

  1. Upgrade to a GPUStack release that includes commit 4e20551 (post-2.2.1) as soon as possible.
  2. Don’t expose worker port 10150 beyond the server that needs to reach it. Firewall or network-policy the worker API to only the GPUStack server’s address — it should never be reachable from arbitrary pods, hosts, or the internet.
  3. In Kubernetes deployments, apply NetworkPolicies restricting ingress to worker pods to the server component specifically, rather than relying on namespace isolation alone.
  4. Review worker logs and access logs for the affected window for requests to /debug, /serveLogs, /serveLogOptions, or /benchmark_logs from unexpected sources — these endpoints had no auth to fail, so any hit outside normal server-proxy traffic is suspicious by definition.
  5. Treat any prompts/completions that transited an exposed worker as potentially disclosed, and rotate or notify accordingly if those workloads handled sensitive data.

References