The Exploit Bulletin — Tuesday, November 10, 2026: 5 issues require action
Tuesday, November 10, 2026 — 5 issues require action. If you run none of the software below, you are done.
Affects: SignalWire FreeSWITCH · IBM Aspera Faspex · GPUStack · npm/@ethersphere/bee-js · Google Chrome stable
1. Unauthenticated code injection in FreeSWITCH gives command execution and credential disclosure (CVE-2026-116779)
CISA KEV (due 2026-11-12) · REMOTE CODE EXECUTION · CRITICAL · CVSS 9.8
CISA added this flaw to KEV on 2026-11-09 with a three-day remediation deadline, and a public exploit is already available, so any FreeSWITCH instance still below 1.11.3 that is reachable from untrusted networks can be taken over by anyone running the exploit.
FreeSWITCH before 1.11.3 contains a code injection flaw reachable by a remote unauthenticated attacker over the network. Successful exploitation discloses configuration and credentials, allows arbitrary call control, and permits command execution on the host running the softswitch.
Affected: SignalWire FreeSWITCH < 1.11.3
How to Test: Check the running FreeSWITCH version from the console or your package manager; anything below 1.11.3 is affected. On exposed instances, review FreeSWITCH logs and host logs for unexpected configuration reads, unknown or anomalous call activity, and unexpected processes or outbound connections spawned by the FreeSWITCH service user, and rotate any SIP, database, or API credentials stored in the configuration if compromise is suspected.
How to Patch: Upgrade to FreeSWITCH 1.11.3 (release tag v1.11.3; fix in commit 7015f6a73ab3d67fed5fbfc277ecfb88a74c2a86 via pull request #3135). Until the upgrade is done, restrict network access to the FreeSWITCH instance so that it is not reachable from untrusted networks.
Evidence: CISA KEV · VulnCheck KEV · CISA SSVC: active · CISA alert: four KEV additions based on evidence of active exploitation · SecurityWeek: FreeSWITCH vulnerability exploited in attacks · VulnCheck XDB public exploit
2. Authorization bypass to full admin in IBM Aspera Faspex 5 (CVE-2026-123218)
CISA KEV (due 2026-11-12) · AUTHENTICATION BYPASS · CRITICAL · CVSS 9.8
CISA added this flaw to KEV on 2026-11-09 with an unusually short three-day remediation deadline, and Faspex servers left on 5.0.19 or earlier are exposed to attackers who can take administrative control of the transfer system and the data it holds.
IBM Aspera Faspex 5.0.0 through 5.0.19 incorrectly enforces authorization, letting a user craft a specific message to bypass authorization checks and gain full administrative privileges on the file-transfer server. IBM rates it CVSS 9.8 and offers no workaround other than upgrading.
Affected: IBM Aspera Faspex 5.0.0 - 5.0.19
How to Test: Check the running Faspex version: anything in the 5.0.0–5.0.19 range without PL1 is vulnerable; after upgrading, validate that the faspex-core container image is 5.0.19 (1ce4b13, Fix Pack: 1). Review Faspex application and access logs for unexpected privilege changes, new or modified administrator accounts, and administrative actions performed by ordinary user accounts.
How to Patch: Upgrade to IBM Aspera Faspex 5.0.19 PL1 (Linux) following IBM's fix instructions; IBM lists no workarounds or mitigations, so if the upgrade must wait, restrict network access to the Faspex server to trusted sources in the interim.
Evidence: CISA KEV · VulnCheck KEV · CISA SSVC: active · CISA Adds Four Known Exploited Vulnerabilities to Catalog · SecurityWeek: IBM Aspera Faspex, SignalWire FreeSwitch Vulnerabilities Exploited in Attacks · The Hacker News: CISA Warns of Active Exploitation of OpenSSH, GPUStack, FreeSWITCH, and IBM Flaws
3. Loopback-trust authentication bypass gives unauthenticated admin and code execution in GPUStack (CVE-2026-102895)
CISA KEV (due 2026-11-12) · REMOTE CODE EXECUTION · CRITICAL · CVSS 9.8
CISA added this flaw to KEV on 2026-11-09 with a 2026-11-12 remediation deadline, and the project reports a v2.1.1 deployment compromised through attacker-created custom backends running reverse shells, so an exposed server left on a pre-2.2.0 build is a full takeover waiting to happen.
GPUStack before 2.2.0 promotes any request it judges to originate from loopback — derived from the reverse-proxy TCP peer or an attacker-supplied X-GPUStack-Real-IP header — to the built-in administrator account whenever force_auth_localhost is False, which is the default. An unauthenticated attacker gets full administrative control: 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.
Affected: GPUStack (pip gpustack) < 2.2.0
How to Test: Check the installed package version (pip show gpustack, or the running server's version) — anything below 2.2.0 is affected, with highest risk for servers behind a reverse proxy or reachable from untrusted networks. Review the inference backends list for custom backends you did not create (especially ones added via the from-yaml endpoint), review administrator API keys for unrecognized persistent keys, and inspect web/proxy access logs for POST /v2/inference-backends/from-yaml and for external requests carrying an X-GPUStack-Real-IP header. On workers, look for unexpected child processes or outbound reverse-shell connections; if anything is found, treat worker and cloud-provider secrets held by GPUStack as exposed and rotate them.
How to Patch: Upgrade to GPUStack v2.2.0 (release tag v2.2.0; fix landed in PR #5346 / commit 53f42a6). If the upgrade must wait, set force_auth_localhost to True — the loopback promotion only applies when it is False — and restrict network access to the GPUStack server API to trusted hosts.
Evidence: CISA KEV · VulnCheck KEV · CISA SSVC: active · CISA adds CVE-2026-102895 to KEV based on evidence of active exploitation · GitHub advisory: observed exploited in the wild against a v2.1.1 deployment
4. Ethersphere bee-js 13.3.0 and Swarm Desktop 0.56.2 release automation hijacked to ship wallet stealer and backdoor
SUPPLY-CHAIN COMPROMISE · CRITICAL
Hosts that installed either release are backdoored and their node keys stolen; until they are rebuilt and the keys rotated, attackers keep access and can drain funds.
Attackers abused Ethersphere's own release automation to publish malicious bee-js 13.3.0 (the JavaScript library behind Swarm Desktop and swarm-cli) and Swarm Desktop 0.56.2. Both download and run code that steals the Swarm node wallet key and its stored password, and install a backdoor on Windows, macOS and Linux. The releases have been taken down and a clean Swarm Desktop release published.
Affected: npm @ethersphere/bee-js 13.3.0; Swarm Desktop 0.56.2
How to Test: Search lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml), CI caches and node_modules for bee-js 13.3.0, including as a transitive dependency of swarm-cli. Check endpoints for Swarm Desktop 0.56.2. On any match, look for unexpected persistence (scheduled tasks, launch agents, systemd units) and outbound connections made after the install.
How to Mitigate: Pin bee-js to a known-good version other than 13.3.0, upgrade Swarm Desktop to the clean maintainer release, rebuild affected hosts, move funds to a new Swarm node wallet key and password, and rotate any secrets on hosts or CI runners that installed the malicious versions.
Evidence: The Hacker News: Ethersphere bee-js and Swarm Desktop compromised · SC Media: Ethersphere project targeted in supply chain attack
5. Use-after-free in Chrome's XML component enables code execution (CVE-2026-125350)
REMOTE CODE EXECUTION · HIGH
Google confirmed on 2026-11-09 that an exploit for this flaw exists in the wild and pushed an emergency update — the eighth exploited Chrome zero-day of 2026 — so any fleet not updated and relaunched today is running a browser with a known weaponized bug.
A use-after-free in Chrome's XML component, reported anonymously on 2026-11-06, lets a malicious web page corrupt memory and execute code in the browser. Google shipped an emergency stable-channel update on 2026-11-09 and states that an exploit exists in the wild.
Affected: Google Chrome stable builds prior to the emergency update released 2026-11-09
How to Test: Open Chrome's About page (Help > About Google Chrome) and confirm the browser is on the stable build released 2026-11-09 or later; a pending-update indicator means the fix is downloaded but not applied until relaunch. For managed fleets, pull the browser version report from your management console and flag any endpoint still on a pre-2026-11-09 stable build.
How to Patch: Update Chrome to the stable release Google issued on 2026-11-09 and relaunch the browser so the update takes effect; in managed environments push the update and force a relaunch rather than waiting for users to restart.
Evidence: VulnCheck KEV · BleepingComputer quoting Google: an exploit for CVE-2026-125350 exists in the wild · The Hacker News: Chrome XML use-after-free under active exploitation · SecurityWeek: Chrome update patches exploited XML zero-day
Read on the web · Every past edition
The Exploit Bulletin is free and daily. It publishes only what security teams must act on today — nothing else. Forward it freely.
Spot an error, or an exploit we missed? Reply here or email [email protected].
