CISA adds exploited FreeSwitch and GPUStack flaws to KEV, with a three-day patch deadline

CISA added two critical vulnerabilities to its Known Exploited Vulnerabilities catalog on Monday 9 November 2026: a code injection flaw in SignalWire FreeSwitch and an authentication bypass in GPUStack. Both carry a CVSS score of 9.8. Under BOD 26-04, federal agencies have three days to apply mitigations, with a due date of 12 November 2026.

SecurityWeek reported the additions on 10 November. The same article covers two other exploited flaws, an IBM Aspera Faspex authorization bypass and the OpenSSH "SSHole" bug, which are separate stories.

What happened

SignalWire published its advisory on 28 October and released FreeSwitch 1.11.3 with patches. The advisory says exploitation "has been observed in the wild" but gives no details on the attacks. Nobody has published a write-up of what those attacks looked like, and the KEV entry lists ransomware use as unknown.

GPUStack's advisory covers versions before 2.2.0, and 2.2.0 is the fixed release. The CNA description says exploitation was observed against a 2.1.1 deployment. SecurityWeek puts that observation at the end of July. The KEV entry was added on 9 November, so the gap between the observed attack and the catalog listing is a few months, not a few hours.

How the FreeSwitch bug works

FreeSWITCH is a software telecom stack, so it sits in front of SIP traffic. The vulnerable function, sofia_presence_handle_sip_i_message(), handles inbound SIP MESSAGE requests. It splits the To user on a plus sign and treats the left-hand side as a chat protocol selector. Pick the api chat proto and the request reaches switch_api_execute(), which runs FreeSWITCH API commands, including ones that reach the operating system, with the daemon's privileges.

Two details make this worse than a typical authenticated-only bug. Inbound chat is enabled on the stock internal and external profiles, and any authenticated profile account is enough. Stock directory users without password material can also remove that barrier in affected configurations, according to the NIST advisory quoted by SecurityWeek. The result is configuration and credential disclosure, arbitrary call control, and command execution.

How the GPUStack bug works

GPUStack is an open-source GPU cluster manager for model serving and GPU instance provisioning. In get_current_user in gpustack/api/auth.py, a request from loopback was treated as the built-in administrator when force_auth_localhost was false, which was the default. A remote request could look like it came from 127.0.0.1 because client_ip_getter accepted a same-host reverse proxy peer or a client-supplied X-GPUStack-Real-IP loopback value.

That gets an unauthenticated attacker administrative access: user and model changes, persistent administrator API-key creation, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml. The API key creation is the part that outlives the bug. A key minted during the bypass keeps working after the upgrade unless someone goes looking for it.

HackZoneLabs assessment

The FreeSwitch flaw is the one we'd move on first. It's reachable over SIP, the stock profiles accept inbound chat, and the path ends at OS command execution with the daemon's privileges. A phone system that runs as root and answers on a public interface is a bad combination, and the vendor's own advisory says it has been exploited. The lack of attack detail cuts both ways: we can't tell you what to grep for, and we wouldn't read the silence as evidence the attacks were narrow.

GPUStack is a narrower exposure but a messier cleanup. It's an AI infrastructure component, which means it often sits on a network with cloud credentials and model endpoints behind it. The advisory's list of what the bypass reaches is effectively a list of what to audit: administrator API keys, worker secrets, cloud-provider credentials. Patching to 2.2.0 closes the door. It doesn't revoke anything that walked through it.

We'd treat the three-day KEV deadline as the floor, not the target. The FreeSwitch advisory is from 28 October and the GPUStack exploitation was observed in July, so both have been available to attackers for a while.

What remains unknown

Neither advisory describes the attacks. There's no public information on who was targeted, how many systems were hit, or what was done after access. The KEV entries list ransomware use as unknown for both, which means CISA hasn't tied either to a ransomware operation, not that neither was used in one.

For GPUStack, the source doesn't say how the July exploitation was spotted or whether the affected deployment was internet-facing. For FreeSwitch, it doesn't say which configurations were hit or whether the attackers needed a valid account.

What to check first

• FreeSwitch: find every instance, including ones behind a session border controller, and get to 1.11.3. Then check whether inbound chat needs to be enabled on the internal and external profiles at all, and whether directory users exist without password material.
• GPUStack: upgrade to 2.2.0, then rotate administrator API keys and any worker or cloud-provider secrets the instance could reach. Check for API keys you can't account for.
• Both: if either service is reachable from the internet and you can't patch today, take it off the internet. The KEV required action allows discontinuing use where mitigations aren't available.

CVE references

CVE-2026-116779

CVE-2026-102895