On November 9, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added three vulnerabilities from GPUStack, SignalWire FreeSWITCH, and IBM Aspera Faspex to its Known Exploited Vulnerabilities (KEV) catalog. All three entries have a remediation deadline of November 12, 2026. The same batch also included the OpenSSH vulnerability CVE-2026-123158, which Global Tech Live has covered separately and whose technical details are not repeated here. CISA confirms that these vulnerabilities have evidence of real-world exploitation; however, the catalog does not disclose information about attackers, victims, scale of activity, or specific exploitation dates. All three announcements record a CVSS 3.1 base score of 9.8, indicating technical severity but not frequency of exploitation or extent of impact.

GPUStack's Loopback Trust Issue

According to GPUStack’s official security announcement, versions prior to 2.2.0 would elevate requests identified as originating from a loopback address to built-in administrator privileges when the default setting force_auth_localhost was set to false. There are two documented paths through which external requests can be mistakenly recognized as coming from 127.0.0.1: one involves a local reverse proxy forwarding remote traffic via a local TCP peer to GPUStack, and the other involves a client forging an X-GPUStack-Real-IP request header. The core issue is not that attackers already possess administrator credentials, but rather that the system incorrectly treats network origin as an authentication signal; both paths ultimately cause the application to treat remote requests as if they were local administrator requests.

The vendor states that exploitation via either path allows enumeration or modification of users, models, worker nodes, and configurations, creation of long-lived administrator API keys, and access to worker node and cloud service credentials. When combined with a backend import function exclusive to administrators, this enables code execution on worker nodes. These impacts stem from GPUStack’s announcement and do not represent outcomes for all deployments. Version 2.2.0 removes the loopback automatic administrator path and tightens header forwarding handling. The vendor lists versions below 2.2.0 as affected. GPUStack also notes that this vulnerability has been observed being used in the wild, although it has not disclosed the total number of victims or scale of activity.

FreeSWITCH Message Processing Path

SignalWire's announcement indicates that inbound SIP MESSAGE handling in FreeSWITCH will split the To user field at the plus sign, treating the left portion as the chat protocol name. The api chat interface registered by mod_dptools subsequently passes the address to a command execution function, thus allowing an attacker who can send MESSAGE to a vulnerable SIP profile to choose the FreeSWITCH API commands executed on the server. The commands run with FreeSWITCH process privileges and may result in configuration and credential disclosure, call control, and operating system command execution.

This vulnerability affects versions 1.11.2 and earlier, with versions 1.11.3 and later marked as fixed. The authentication barrier cannot be generalized to all scenarios as requiring accounts: the vendor states that in common affected configurations, a single profile account is sufficient, while some stock directory users without password material further lowers the barrier. The announcement also notes that default internal and external profiles will process chat messages unless explicitly set with enable-chat=false; the vendor confirms this attack path has been observed in the wild.

Aspera Announcement Retains Permission Conflict

IBM's announcement describes CVE-2026-123218 as an authorization bypass issue in Aspera Faspex 5: attackers can construct specific messages to obtain full administrator privileges. IBM's listed affected range is 5.0.0 through 5.0.19, with the fixed version being 5.0.19 PL1 on Linux, and requires verification that the faspex-core container image corresponds to Fix Pack 1 for 5.0.19. The announcement's mitigation section indicates there are no temporary workarounds, therefore the public vendor remediation path is upgrade. IBM first released this security announcement on November 7, followed by CISA adding the vulnerability to the KEV directory on November 9.

IBM's same announcement contains unresolved internal contradictions regarding exploitation prerequisites. The summary and body use 'authenticated user' and 'authorized user', implying that attackers must first have some form of access condition; however, the CVSS 3.1 vector on the same page includes PR:N, indicating no existing privileges are required. The existing materials are insufficient to determine which description is accurate, thus the article retains both descriptions and does not characterize the Aspera vulnerability as already confirmed to be triggerable by completely unauthenticated remote attackers.

Disposal Deadlines and Evidence Boundaries

CISA has recorded known ransomware activities for three entries as Unknown, which cannot be rewritten to confirm the existence or non-existence of ransomware exploitation. Directory requirements mandate mitigation according to vendor specifications, assess internet exposure in accordance with BOD 26-04, and execute forensic triage requirements; in applicable circumstances, if no mitigating measures are available, products should be discontinued in accordance with relevant guidance. November 12th is the deadline set by the directory for this batch of entries, not a vendor commitment that all customers will complete upgrades before that date. The same deadline does not mean that these three vulnerabilities have identical triggering conditions or disposal steps.

Editorial analysis: The three vulnerabilities are located in AI infrastructure management, communication servers, and enterprise file transfer systems, but the common risk stems from authentication, authorization, or message dispatch boundaries being incorrectly trusted. KEV status elevates disposal priority but does not prove that each exposed instance has been compromised; after deploying patched versions, whether to expand investigations should still be determined based on CISA forensic requirements and local evidence judgment. SecurityWeek's public metadata independently confirms the CISA added entries and publication times. This article's technical conditions, versions, and mitigation information are all based on CISA and three vendor materials.