OpenSSH, GPUStack, FreeSWITCH and IBM Aspera Faspex: Four Exploited Flaws Added to CISA KEV

CISA added four actively exploited flaws to the Known Exploited Vulnerabilities (KEV) catalog on Monday, November 9, 2026, all with the same remediation due date of November 12. They are CVE-2026-123218 in IBM Aspera Faspex, CVE-2026-116779 in FreeSWITCH, CVE-2026-123158 in OpenSSH, known as SSHole, and CVE-2026-102895 in GPUStack. Three score 9.8 Critical and the fourth 8.1 High, and each already has a vendor fix. Federal agencies get three days.

IBM Aspera Faspex: CVE-2026-123218

IBM's security bulletin, first published November 7, 2026, describes an authorization bypass. Aspera Faspex 5.0.0 through 5.0.19 could allow an authorized user to craft a specific message to bypass user authorization and gain full administrative privileges. IBM rates it 9.8 Critical (CWE-863, incorrect authorization) and lists no workaround. The vector says no privileges are required, although the description speaks of an authorized user.

The fix is Aspera Faspex 5.0.19 PL1 for Linux, applied by patching the container images. IBM's check is that the faspex-core container image reads 5.0.19 (1ce4b13, Fix Pack 1). The bulletin does not mention exploitation and does not say what the specific message is, and THN says no public reports describe how this flaw is being exploited, by whom or at what scale. The KEV listing rests on CISA's SSVC data: Active, Automatable, Total impact. VulnTracker shows EPSS at 0.4%.

FreeSWITCH: CVE-2026-116779

The GitHub advisory, dated October 28, 2026, says that before 1.11.3 the inbound SIP MESSAGE handler split the To user on a plus sign and treated the left side as a chat protocol selector. Selecting the api protocol reached switch_api_execute(), which lets a peer whose MESSAGE was accepted run FreeSWITCH API commands, including operating-system command sinks, with the daemon's privileges. The advisory says the flaw permits configuration and credential disclosure, arbitrary call control and command execution, and that exploitation has been observed in the wild. It is rated 9.8 Critical (CWE-77, CWE-78, CWE-749).

No non-default setting is needed. Inbound chat is on in the stock internal and external profiles, the inbound ACL does not cover MESSAGE, and where MESSAGE authentication is enforced any one account on the profile is enough. The stock directory also defines a user named default with no password. SSVC reads Active, Automatable, Total impact, and VulnTracker shows EPSS at 1.3% and lists the flaw under both FreeSWITCH and SignalWire.

OpenSSH: CVE-2026-123158, SSHole

OpenSSH 10.6p2, released November 5, 2026, avoids a password authentication bypass that affects some Linux systems when sshd is built and run with PAM support disabled. The release notes call it a critical workaround for systems that use musl libc and say the root cause lies outside sshd but is exploitable through it. The CVE record, assigned by MITRE, scores it 8.1 High (CWE-394) and says that for some account configurations any password between 256 and 1024 characters succeeds.

Alpine Linux's post spells out the conditions. The attacker needs the name of an account whose password field is *, the machine needs at least one other account with a $5$ or $6$ password hash, and the password sent is 257 to 1024 bytes long. The affected setup is Alpine's openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no, with PasswordAuthentication left at its default of yes. Locked accounts marked ! are not affected, and neither is UsePAM yes.

Exploitation followed the patch within days, though reports differ on the start. BleepingComputer says attempts began on November 5, the day a proof of concept appeared. THN cites Previdian for 22 attempts from 14 unique IP addresses since November 6. GreyNoise recorded its first successful exploitation at 00:46 UTC on November 7, about 40 hours after the fix, and BleepingComputer reports 16 successful chains from six source addresses, in one case with root access and a Python command-and-control agent called TAC Agent. SSVC reads Active, Not automatable, Total impact.

GPUStack: CVE-2026-102895

The GitHub advisory, dated July 31, 2026, describes an authentication bypass in GPUStack, a GPU cluster manager for AI model serving. Before 2.2.0, get_current_user treated a loopback request source as the built-in administrator when force_auth_localhost was false, which was the default. A request could appear to come from 127.0.0.1 through a same-host reverse proxy, with no header or credential needed, or through a client-supplied X-GPUStack-Real-IP header. The result is unauthenticated administrative access, including user and model changes, persistent administrator API keys, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml.

The advisory says exploitation was observed against a 2.1.1 deployment, with attacker-created custom backends running reverse shells, reported by Javier Sixto of ulex.fr. The fix in 2.2.0 removes the loopback auto-admin path and hardens the client-IP and forwarding-header handling. It is rated 9.8 Critical (CWE-287, CWE-290, CWE-346), SSVC reads Active, Automatable, Total impact, and VulnTracker shows EPSS at 0.3%. The CVE record was published on November 4, 101 days after the advisory.

Four trust decisions made on input the attacker controls

The four entries have different products and different causes, but the descriptions share a shape. In each one, the software made a trust decision using a value the sender controls.

None of the descriptions points to memory corruption. They read as logic and validation errors, and the trigger is a request the service already accepts: a SIP MESSAGE, an HTTP call, an SSH password attempt. That is why the dependable controls are the update itself and keeping these services off untrusted networks. Nothing in this list depends on a malformed packet that a filter could be expected to catch.

Reading it on VulnTracker

A few things stand out on the pages as of November 10. The scores come from different sources: IBM for Aspera Faspex, GitHub for FreeSWITCH and GPUStack, and MITRE for OpenSSH. EPSS is low across the board, which is typical for entries this new, so the KEV flag and the SSVC reading tell you more than the percentage does. SSVC says Total technical impact for all four, and Automatable for every one except OpenSSH. All four remediation guide fields read "No guide yet" and the vendor advisory fields are empty, so the fixes in this post come from the vendor pages linked in References. The Exploits tab lists 30 entries for OpenSSH, 2 for FreeSWITCH and 1 for IBM Aspera Faspex. Alpine Linux appears on the OpenSSH page as "Runs on, not affected", which is a reminder to read the affected-product list before assuming an entry applies to your distribution.

What to do

The KEV due date is Thursday, November 12. Start with whichever product faces the internet, since exposure decides how fast each of these can be reached.

IBM Aspera Faspex

1. Upgrade to 5.0.19 PL1 by patching the container images, following IBM's patching instructions.
2. Confirm the faspex-core image reads 5.0.19 (1ce4b13, Fix Pack 1).
3. There is no workaround, so patching is the only mitigation. As a precaution, review administrator accounts for any you do not recognize.

FreeSWITCH

1. Upgrade to 1.11.3 or later.
2. If you cannot upgrade yet, set enable-chat=false on every profile that does not need SIP chat. The advisory says auth-messages alone is not sufficient and disable_system_api_commands=true does not close the path.
3. Remove the passwordless default directory user or give it a password, and leave the new enable-chat-api-proto parameter off.
4. As a detection idea of our own, not vendor guidance, look in SIP logs for MESSAGE requests whose To user begins with api+.

OpenSSH

1. Upgrade to OpenSSH 10.6p2 or your distribution's patched build. On Alpine, run apk upgrade -U -a and then restart sshd, for example with rc-service sshd restart, because the upgrade alone does not replace the running daemon.
2. As a workaround, set PasswordAuthentication no.
3. Check /etc/shadow for accounts whose password field is *, and look for password logins to those accounts, unexpected entries in authorized_keys, TAC Agent, and unfamiliar startup services. Tiny-cloud images on Alpine 3.18.11 through 3.24.3 ship an alpine user with * and passwordless doas, so check those first.

GPUStack

1. Upgrade to 2.2.0.
2. Without upgrading, set force_auth_localhost=true, strip any client-supplied X-GPUStack-Real-IP header at the edge, make sure a same-host proxy cannot turn external traffic into loopback traffic, and keep the API off untrusted networks.
3. Review API keys, custom inference backends created through from-yaml, and rotate worker and cloud-provider secrets.

Federal civilian agencies follow the required action in each KEV entry under BOD 26-04. Everyone else can use the same date as a sensible internal deadline.

Takeaway

Every one of these four has a fix, and CISA gave three days for all of them. The public record is uneven: FreeSWITCH, GPUStack and OpenSSH have detailed accounts of how the flaw works and, in the case of OpenSSH, of what attackers did after the patch, while IBM's bulletin says little beyond the version range and the fix. Do not wait for more detail on Aspera Faspex before patching it. To follow these four and anything else CISA adds, add them to your Track List on VulnTracker.

References

• IBM security bulletin for Aspera Faspex
• FreeSWITCH advisory GHSA-mg63-h38w-8p9p
• OpenSSH release notes
• Alpine Linux post on the OpenSSH password authentication bypass
• GPUStack advisory GHSA-gj9m-f8ph-pmhr
• CVE.org records: CVE-2026-123218, CVE-2026-116779, CVE-2026-123158, CVE-2026-102895
• NVD entries: CVE-2026-123218, CVE-2026-116779, CVE-2026-123158, CVE-2026-102895
• CISA KEV catalog entries: CVE-2026-123218, CVE-2026-116779, CVE-2026-123158, CVE-2026-102895
• CISA BOD 26-04