CISA puts GPUStack on the KEV catalog: an unauthenticated attacker takes over an AI GPU cluster
On November 9, 2026, CISA added four actively exploited flaws to its KEV catalog, including a CVSS 9.8 authentication flaw in GPUStack that hands administration of a GPU cluster to an unauthenticated attacker. Teams running this manager should move to 2.3.0 and then revoke every exposed secret, because the patch does not invalidate keys already stolen.
November 9, 2026. CISA added four flaws to its KEV (Known Exploited Vulnerabilities) catalog. CVSS 9.8. That is the score of the most severe of them: an authentication flaw in GPUStack, an open-source GPU cluster manager for AI model serving. November 12. That is the remediation deadline imposed on U.S. federal agencies. Why it matters: for the first time, a piece of self-hosted AI infrastructure lands on the KEV catalog, and the flaw lets an unauthenticated attacker become a cluster administrator — down to extracting its cloud secrets.
What the KEV catalog is, and why this entry matters
The KEV catalog is not a list of severe flaws: it is a list of exploited flaws. CISA only adds a CVE when it has evidence that an actor is using it right now. A high CVSS score is not enough — it requires observed in-the-wild exploitation.
The November 9 batch gathers four products with nothing in common except that signal:
- GPUStack — CVE-2026-102895, improper authentication, versions before 2.2.0;
- SignalWire FreeSWITCH — CVE-2026-116779, code injection, versions before 1.11.3;
- OpenBSD OpenSSH — CVE-2026-123158, password authentication bypass,
sshdbefore 10.6p2 on musl without PAM; - IBM Aspera Faspex — CVE-2026-123218, incorrect authorization, 5.0.0 through 5.0.19.
Two of those labels name authentication or authorization outright. That split matters for triage: access-control flaws give attackers a clean, scriptable path in and leave fewer traces than a crash or a memory-corruption exploit.
GPUStack: the open admin door
GPUStack is a GPU cluster manager for model serving and GPU-instance provisioning, distributed under the Apache 2.0 license. Its promise is simple: turn a fleet of graphics cards into an inference platform with a single control plane. That position is exactly what makes the flaw expensive: a GPU manager holds the credentials of the clouds and workers it orchestrates.
CVE-2026-102895 is an improper authentication flaw. The reported impact reads like a full takeover: an unauthenticated attacker can reach administrative functions, change users and models, create administrator API keys, and pull worker and cloud-provider secrets. Code execution comes through the POST /v2/inference-backends/from-yaml endpoint, which accepts an inference definition in YAML form. Researchers report exploitation observed against a 2.1.1 deployment — the familiar pattern of attackers hitting installs that lag a few releases behind.
The fix is version 2.2.0. But stopping there would be a mistake: the project’s GitHub releases list v2.3.0 as the latest stable on November 9, and a vulnerability database entry dated November 4 flags a separate authorization issue, CVE-2026-103002, covering 2.2.0 through 2.2.2. The prudent reading fits in one sentence: run the latest stable 2.3.0, not just 2.2.0.
Part of the danger is the tool’s position in the stack. GPUStack sits above the fleet of inference runtimes — vLLM, Ollama, SGLang — and below the cloud, which means a single compromise cascades: the attacker is not stuck inside one model server, they are at the control plane that provisions every GPU and holds every token.
The trap that outlives the patch: secrets
The most durable part of this flaw is not the code but the credentials. A GPU manager keeps tokens for the clouds and workers it drives. If an attacker minted an admin API key or copied a cloud token before you upgraded, installing 2.2.0 closes the door without invalidating the stolen keys.
The response is therefore twofold: patch, then revoke. Teams should rotate worker and cloud-provider credentials and revoke any API key they cannot account for. That is the difference between fixing a vulnerability and closing an incident.
Put another way, the patch and the rotation are two separate jobs. A version bump stops the bleeding; only credential rotation closes the hole for good, because an attacker who minted an admin key before the patch keeps that key working afterward. Treat the two as a single change window, not two optional tasks. GPUStack is also exactly the kind of tool small AI teams run on a single workstation or VPS and then forget: it is open source, quick to deploy, and its admin UI is often left reachable from the internet for convenience.
The other three entries, one line each
FreeSWITCH (CVE-2026-116779) hits a telephony engine that by design accepts messages from strangers: a code-injection via a crafted SIP message can hand an attacker both a foothold and a toll-fraud platform. OpenSSH (CVE-2026-123158) is the narrowest of the four — only musl systems without PAM, typically minimal containers and appliances, are exposed, and Portable OpenSSH 10.6p2 had already fixed the flaw since November 5 (we covered it in our analysis of the sshole bypass). IBM Aspera Faspex (CVE-2026-123218) is a large-file transfer server whose incorrect authorization is fixed by container image 5.0.19 PL1, with no documented workaround.
What unites the four entries is the calendar: added November 9, due November 12 on the federal side. Teams that cleared their list on a Friday face a fresh one on Monday.
How to check your exposure in a minute
Triage is quick, product by product. For GPUStack, just compare your installed version against 2.3.0 — the admin UI or the releases page is enough; there is no dedicated command to hunt for. For OpenSSH, the flaw only hits musl builds without PAM, and two commands settle the question:
sshd -V 2>&1 | head -n 1
ldd "$(command -v sshd)" | grep -Ei 'musl|libpam'If sshd -V reports a version older than 10.6p2 and ldd shows musl without libpam, you are in scope: move to 10.6p2 or later. For FreeSWITCH and Aspera Faspex, the rule is the same — confirm the deployed version against the fix threshold, then schedule the patch.
Why this is a deeper signal
GPUStack entering the KEV marks a change of nature. Self-hosted AI infrastructure — GPU clusters, inference orchestrators, model registries — has become a target in its own right, alongside VPNs, firewalls and mail servers. The reason is mechanical: these tools concentrate expensive GPUs and cloud credentials in a single administration point, often exposed for convenience.
The attack pattern is that of an evolved cryptojacking: an attacker who controls a GPU cluster can mine, exfiltrate secrets, or reconfigure inference to serve their own models. The cost is no longer just an electricity bill — it is the compromise of the cloud account that funds the cluster. That is why the response is not only a version bump but a credential rotation: the attacker’s prize is the account, not the hardware.
Verdict
If you run GPUStack on a version before 2.2.0, upgrade to 2.3.0 immediately, then rotate worker and cloud-provider credentials and revoke any unknown API key — in that order, patch first, revoke second, never the reverse. The flaw is exploited in the wild, which changes the stakes: you are not closing a theoretical threat, you are shutting a door an actor is already trying to open. For the other three entries, apply the matching fix (FreeSWITCH beyond 1.11.2, OpenSSH 10.6p2, Aspera Faspex 5.0.19 PL1) and treat November 12 as your own deadline, not a constraint reserved for federal agencies.