![CISA Adds 4 Exploited Flaws, Feds Due Nov. 12 [2026]](https://shattered.io/wp-content/uploads/2026/11/cisa-kev-gpustack-freeswitch-openssh-aspera-faspex-nov-12-2026-gen.webp)
CISA put four actively exploited flaws on its Known Exploited Vulnerabilities list on Monday, Nov. 9, and federal civilian agencies have until Thursday, Nov. 12 to fix them. The additions cover GPUStack (CVE-2026-102895), SignalWire FreeSWITCH (CVE-2026-116779), OpenBSD OpenSSH (CVE-2026-123158) and IBM Aspera Faspex (CVE-2026-123218). CISA updated its notice on Nov. 10, which is why anything that still says three products were added is out of date.
The four products have little in common. One manages GPU clusters for AI model serving, one runs voice and video calls, one is the remote-login daemon on a huge share of servers, and one moves large files between enterprises. What ties them together is the evidence behind the listing: CISA only adds a bug to the CISA KEV catalog when it has proof that someone is exploiting it in the wild. A high severity score is not enough.
The batch also lands in a busy week. CISA added a WordPress Core race condition on Nov. 3 and, according to research notes on CISA’s alert feed, a SonicWall SSLVPN single-factor-authentication flaw on Nov. 6. Security teams that cleared one list on Friday now face another on Monday. Below, the four new entries are sorted by exposure, each vendor’s fix path is laid out, and the three-day federal clock is translated for everyone who is not a federal agency.
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
The four CISA KEV additions at a glance #
CISA’s own labels are short and dry, so the table below keeps them and adds the affected ranges that public vulnerability records give for each product. Every row reflects the Nov. 9 addition and the Nov. 12 remediation date for federal agencies.
| Product | CVE | CISA label | Affected range | Action |
|---|---|---|---|---|
| GPUStack | CVE-2026-102895 | Improper authentication | Versions before 2.2.0 | Move to 2.2.0 or later |
| SignalWire FreeSWITCH | CVE-2026-116779 | Code injection | Versions before 1.11.3 | Upgrade past 1.11.2 |
| OpenBSD OpenSSH | CVE-2026-123158 | Unexpected status code or return value | sshd before 10.6p2 on Linux with musl libc and no PAM | Move to 10.6p2 or later |
| IBM Aspera Faspex | CVE-2026-123218 | Incorrect authorization | 5.0.0 through 5.0.19 | Patch container image to 5.0.19 PL1 |
| All four | n/a | Evidence of active exploitation | n/a | Added Nov. 9, due Nov. 12 |
Two of the four labels name authentication or authorization failures outright, and third-party researchers describe the OpenSSH entry as a password authentication bypass. Only one, FreeSWITCH, is a classic injection bug. That split matters for triage. Access-control flaws tend to give attackers a clean, scriptable path in, and they leave fewer traces in logs than a crash or a memory-corruption exploit.
GPUStack CVE-2026-102895: an AI cluster manager with an open admin door #
GPUStack is an open-source GPU cluster manager for AI model serving and GPU-instance provisioning. Its own site says the project is fully open source under the Apache 2.0 license. CISA lists CVE-2026-102895 as an improper-authentication vulnerability and says it is being exploited. Public records place the affected range at versions before 2.2.0 and name 2.2.0 as the fix.
What an attacker gets
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. One research write-up reportedly saw exploitation against a 2.1.1 deployment, which fits a familiar pattern of attackers hitting installs that lag a few releases behind.
The secret exposure is the part that outlasts the patch. A GPU manager holds credentials for the clouds and workers it orchestrates. If an attacker minted an admin API key or copied a cloud token before you upgraded, installing 2.2.0 closes the door but leaves the stolen keys valid. Teams should rotate worker and cloud-provider credentials and revoke any API key they cannot account for.
Versions and release status
GPUStack’s GitHub releases page lists v2.3.0 as the latest release as of Nov. 9. A v2.3.1rc1 build also appeared on Nov. 9, but it is marked a pre-release and does not belong on a production cluster. One vulnerability database entry, dated Nov. 4, reports a separate authorization issue (CVE-2026-103002) for versions 2.2.0 through 2.2.2, and that source does not say whether anyone has exploited it. The safe reading: run the latest stable v2.3.0 rather than stopping at 2.2.0.
FreeSWITCH CVE-2026-116779: code injection in the telephony engine #
FreeSWITCH has powered carriers, contact centers and communication products since 2006, and SignalWire, founded by the same team in 2017, now sells a cloud platform around it. CISA classes CVE-2026-116779 as code injection. Public records say versions before 1.11.3 are affected. Researcher write-ups describe a crafted SIP MESSAGE that lets an authenticated peer run commands through the API, which is a narrower condition than the CISA label alone suggests. Treat that description as third-party analysis, since CISA’s entry does not spell out the mechanism.
One detail deserves attention. SignalWire’s official page says FreeSWITCH v1.11.2 shipped with major security fixes and urged every user to upgrade to it. Because the new flaw hits everything before 1.11.3, a team that followed that earlier advice and stopped at 1.11.2 remains exposed. Reports point to 1.11.3 or later as the remediation level, though only one source in the research says so directly, so confirm against SignalWire’s release notes before you schedule the change.
The packaging story adds friction. SignalWire’s documentation reportedly changed on Oct. 31 so that down prebuilt FreeSWITCH binaries requires a SignalWire account, a SignalWire Space and a personal access token. Teams that pull packages in an automated pipeline may find the fetch step broken at the worst moment. SignalWire also markets FreeSWITCH Advantage as an enterprise branch with commercial support, patches and an SLA, and a vendor-supported branch will likely get the fix on a schedule that the community build cannot promise.
Telephony servers are an awkward target to leave exposed. They sit on the internet by design, they accept messages from strangers, and they often run with broad permissions so they can reach media and call-routing resources. A code-execution bug there hands an attacker both a foothold and a platform for toll fraud.
OpenSSH CVE-2026-123158: a narrow configuration with a wide reputation #
The OpenSSH entry will draw the most clicks and probably the most panic, so precision helps. CISA calls it an unexpected status code or return value vulnerability in OpenBSD OpenSSH. The affected range in the public record is sshd before 10.6p2 on Linux systems that use musl libc and run without PAM. Ostorlab’s write-up headlines it as an OpenSSH musl password bypass fixed in 10.6p2.
The project’s own page lists OpenSSH 10.6 as released on Oct. 6 and Portable OpenSSH 10.6p2 as released on Nov. 5, four days before CISA’s listing. So a fix existed before the catalog entry, and administrators who track OpenSSH releases had a head start. The public record does not name a threat actor, a campaign or an attack vector, and it does not say how many deployments were hit.
The configuration limits help most readers. Many mainstream Linux server installs use glibc and PAM, so the exposed population is smaller than the OpenSSH name implies. Minimal container images and embedded appliances are where musl builds without PAM tend to turn up, and those are also the systems that rarely get a routine patch. The check takes a minute: confirm the libc, confirm whether sshd was built with PAM, and compare the version string against 10.6p2.
sshd -V 2>&1 | head -n 1
ldd --version 2>&1 | head -n 1
ldd "$(command -v sshd)" | grep -Ei 'musl|libpam'
IBM Aspera Faspex CVE-2026-123218: file transfer with incorrect authorization #
Faspex is IBM’s managed file-transfer product, and CISA lists CVE-2026-123218 as an incorrect-authorization vulnerability. Public records identify Faspex 5.0.0 through 5.0.19 as affected. The remediation in those records is to patch the Faspex container image to 5.0.19 PL1, and they report no workaround. Administrators should verify that against IBM’s advisory and container-image documentation before they deploy. Brandefense’s vulnerability entry tracks the same CVE.
The lack of a workaround changes the calculation. With no configuration setting to flip, the only mitigation short of patching is to pull the service off the internet or put it behind a VPN or allowlist. For a file-transfer server that partners reach from outside, that decision involves the business, not just the security team.
Version confusion is a risk here. IBM released Aspera Console 3.4.12 on Oct. 13, but Console is a different product from Faspex and that release does not address this bug. The research found no Faspex release notification, no Faspex release notes and no confirmed Faspex product change over the past three months, so the container fix is the thing to chase. Managed file transfer concentrates sensitive data in one place, which is exactly why an authorization failure there earns a spot on the federal list.
What the Nov. 12 deadline means, and who it binds #
The remediation date applies to Federal Civilian Executive Branch agencies, not to every organization. CISA’s notice reportedly describes Binding Operational Directive 26-04 as the current federal vulnerability-management requirement and says it prioritizes KEV entries on publicly exposed assets that give total control after exploitation. The three-day window between listing and due date is short by any enterprise standard, and it signals how CISA weighs urgency when exploitation is already underway.
Private companies, universities and local governments face no legal clock from the directive. They still carry the risk, and many of them borrow the list as a patching priority anyway. A practical reading: if your asset inventory includes any of the four products and the system faces the internet, treat Nov. 12 as your date too. Teams that want to automate that response can follow a step-by-step KEV tracker build in Python that pulls the catalog and flags matches against an inventory.
The deadline also forces a sequencing question. Three days is not enough to test, stage and roll out four unrelated patches across a large estate. Triage by exposure first, then by what the system holds. A public Faspex node with no workaround outranks an internal GPUStack test box, and both outrank a musl-based sshd on an isolated network segment.
Ten weeks of KEV pressure: how this batch compares #
The Nov. 9 batch is the latest in a run of frequent additions. The table below lists seven CISA alerts from mid-October through Nov. 9 that name specific products, based on the alert titles and entries CISA published. Together they cover 21 catalog entries in under four weeks.
| Alert date | Entries added | Products named |
|---|---|---|
| Oct. 13 | 2 | Microsoft Windows, Ivanti Connect Secure |
| Oct. 14 | 4 | Palo Alto Networks PAN-OS, Cisco Secure Email Gateway, AhsayCBS |
| Oct. 20 | 6 | Plex Media Server, SiteGuard Server Edition, Siemens Software Center |
| Oct. 26 | 2 | PHP |
| Oct. 27 | 2 | Adobe Commerce and Magento, Google Brotli |
| Nov. 3 | 1 | WordPress Core |
| Nov. 9 | 4 | GPUStack, SignalWire FreeSWITCH, OpenSSH, IBM Aspera Faspex |
The mix is the story. Enterprise edge gear shows up (the Palo Alto, Cisco and Ahsay additions from Oct. 14), so do web runtimes and content platforms, and now AI infrastructure and managed file transfer. CISA also added Ivanti Connect Secure flaws on Oct. 13, and a separate alert that day urged patching the newly exploited Ivanti Connect Secure bugs.
The pace did not start in October. Per the research, CISA added six vulnerabilities on Aug. 26, including flaws in Red Hat products, Microsoft SQL Server, Ajax.NET Professional, the Linux kernel and Citrix NetScaler. Activity from that date through Nov. 9 grew steadily and clustered in October and early November, a trend that InfraTrust’s October advisory pulse also tracked for edge devices. CISA also announced a strategy titled CISA 2030: Defend, Harden, Prevail on Oct. 26, which reportedly frames the agency’s longer-term direction.
Why infrastructure software keeps landing on the list #
Look at where the exploited bugs live. None of the four new products is an end-user app. Each one is plumbing: a scheduler, a call engine, a remote shell and a transfer server. Plumbing gets deployed once, forgotten, and updated only when something breaks. It also tends to hold privileged credentials and sit close to the network edge, which makes it more valuable to an attacker than a desktop application.
Lagging versions compound the problem. The GPUStack exploitation report involves a 2.1.1 deployment, which sits behind the fixed 2.2.0 line. FreeSWITCH users who stopped at 1.11.2 are one release behind. In both cases the vendor shipped a fix, and the exposure came from the gap between release and rollout. Patch latency, not zero-day discovery, supplies much of the attacker’s opportunity.
Earlier listings show the same dynamic. A Linux kernel bug nicknamed Fragnesia reached the KEV list after exploitation surfaced, and a VMware ESX flaw with a low severity score made it onto the catalog too. Neither would have topped a CVSS-sorted queue, yet both mattered the moment someone used them. A Nextcloud Collabora flaw reached the list the same way. The lesson repeats across the Nov. 9 batch: severity scores describe potential, and the catalog describes events.
Market and operational impact for vendors and defenders #
For vendors, a KEV listing is a reputational event with a clock attached. GPUStack, SignalWire, the OpenSSH project and IBM each now appear in a federal advisory that customers, auditors and insurers read. The open-source projects face the sharper test, since they cannot assign a support team to every deployment. GPUStack’s fix path is clear and its stable release sits ahead of the fixed version, which helps. IBM’s customers, by contrast, depend on a container patch that administrators must apply themselves.
For defenders, the cost is mostly labor and coordination. Four unrelated products means four owners, four change windows and four rollback plans. Security teams that lack an accurate software inventory lose the most time, because the first hour goes to finding out whether they run any of these tools at all. The AI-infrastructure entry adds a wrinkle: GPUStack often lands in a research or data-science group outside the central IT inventory, so it can slip past the usual scanning.
Insurers and auditors also watch the list. An unpatched KEV entry on an exposed system makes a poor answer in a post-incident review, since the public record shows the exploitation evidence existed. Enterprise software has a recent example of the same pressure in a SharePoint flaw that hit the KEV list. The operational takeaway is that a listing converts an ordinary patch ticket into a documented obligation.
KEV versus CVSS and other triage signals #
Teams choose among several ways to rank patches, and this batch tests each. CVSS scores rate how bad a flaw could be. Vendor advisories say what a vendor will fix and when. Exploit-prediction models estimate how likely exploitation is. The KEV catalog answers a different question: has someone already used this bug? A fuller walkthrough of that tradeoff sits in a comparison of CVSS and KEV prioritization.
For the four new entries, KEV wins on timing. The catalog flagged all four on Nov. 9 with a hard date, while a severity-first queue could easily have ranked a narrow musl-only OpenSSH condition below dozens of generic high scores. By contrast, KEV has blind spots. It only lists bugs with known exploitation, so it lags the first attacker by definition, and it cannot tell you whether a flaw affects your build. Use it as a floor, not a ceiling.
The better approach layers the signals. Start with KEV membership, add exposure (internet-facing or not), then weigh what the system holds. That ordering puts the public Faspex node and an unpatched FreeSWITCH gateway at the front and pushes an internal sandbox to the back without ignoring it. More advisories in the same vein sit in the security coverage hub.
A three-day triage plan for the four flaws #
The table below turns the facts into an order of work. It uses only the affected ranges and fixes from the public records, so confirm each action against the vendor’s own advisory.
| Product | First question to ask | First action |
|---|---|---|
| IBM Aspera Faspex | Is any node on 5.0.0 through 5.0.19 reachable from the internet? | Restrict access, then patch the container image to 5.0.19 PL1 |
| GPUStack | Does any cluster run a version before 2.2.0? | Upgrade to the latest stable release, rotate worker and cloud credentials, review admin API keys |
| FreeSWITCH | Does any gateway run a version before 1.11.3, including 1.11.2? | Upgrade, and check whether pipelines still fetch binaries without a SignalWire token |
| OpenSSH | Is sshd older than 10.6p2 on a musl system without PAM? | Upgrade to 10.6p2 or later, starting with minimal container images |
| Everything above | Which owner holds each system? | Name an owner per product, set a rollback plan, log the change before Nov. 12 |
After patching, hunt for signs of earlier compromise. Exploitation began before the listing, so a clean version number today says nothing about last week. Check authentication logs for unusual logins on the OpenSSH hosts, review SIP MESSAGE traffic on FreeSWITCH gateways, look for unexpected administrator accounts and API keys in GPUStack, and audit Faspex transfer logs for access that did not follow normal sharing rules.
Five predictions for the weeks ahead #
These are analytical judgments, not reported facts, and the research does not confirm any of them.
- More AI-infrastructure tools will join the catalog. GPUStack is the first of its kind in this run, and schedulers, model servers and orchestration layers share its habit of holding cloud secrets behind thin authentication.
- Researchers will publish more musl-related findings. The OpenSSH case exposed how little scrutiny alternate C libraries get, and bug hunters follow a fresh seam.
- Vendors will tighten how they ship binaries. SignalWire’s account-gated downloads point toward more controlled distribution, which helps patch tracking and hurts anyone with a hard-coded download script.
- KEV-first triage will harden into policy. More boards and insurers will ask for proof that exposed systems clear the catalog within days, not weeks.
- A second wave of CVEs will follow in the same products. The database entry for GPUStack CVE-2026-103002 already shows follow-on research, and a fix often draws closer scrutiny of neighboring code.
FAQ: CISA KEV additions of Nov. 9 #
Which four vulnerabilities did CISA add on Nov. 9, 2026?
CISA added CVE-2026-102895 (GPUStack improper authentication), CVE-2026-116779 (SignalWire FreeSWITCH code injection), CVE-2026-123158 (OpenBSD OpenSSH unexpected status code or return value) and CVE-2026-123218 (IBM Aspera Faspex incorrect authorization). CISA updated the notice on Nov. 10.
What is the CISA KEV catalog?
It is CISA’s Known Exploited Vulnerabilities Catalog, a list of flaws backed by evidence of active exploitation. Inclusion tells defenders that attackers are using the bug now, which is a stronger signal than a severity score.
When do agencies have to patch?
The remediation due date in the public records is Nov. 12, 2026, three days after the Nov. 9 listing. The directive applies to Federal Civilian Executive Branch agencies, not to every organization.
Is every OpenSSH server vulnerable to CVE-2026-123158?
No. The public record describes the affected range as sshd before 10.6p2 on Linux systems using musl libc without PAM. Portable OpenSSH 10.6p2 was released on Nov. 5, 2026, so upgrading closes the gap.
Which GPUStack version should I run?
Versions before 2.2.0 are affected, and 2.2.0 carries the fix for CVE-2026-102895. GPUStack’s GitHub page lists v2.3.0 as the latest release, so aim for the latest stable build and avoid the v2.3.1rc1 pre-release on production systems. Also rotate worker and cloud credentials, because the flaw can expose them.
Does FreeSWITCH 1.11.2 protect me?
No. SignalWire urged users to move to 1.11.2 for earlier security fixes, but public records say CVE-2026-116779 affects versions before 1.11.3. Upgrade beyond 1.11.2 and confirm the target release in SignalWire’s notes.
Is there a workaround for the IBM Aspera Faspex flaw?
Available records report none. Administrators should patch the Faspex container image to 5.0.19 PL1 after checking IBM’s advisory, and limit internet exposure of the service until the patch lands.
Do private companies have to follow the KEV deadline?
The binding requirement covers federal civilian agencies only. Private organizations still face the same exploitation risk, and many treat KEV dates as their own patching deadline.