OpenSSH CVE-2026-123158 + 3 more

The top item is that OpenSSH CVE-2026-123158 (nicknamed sshole), which we covered on Nov 6, was added to CISA's KEV (Known Exploited Vulnerabilities) catalog on Nov 9. That means it is being exploited in the wild. It affects sshd on Linux built with musl libc and without PAM: Alpine Linux, Alpine-based containers and cloud images, OpenWrt, and similar. If you run such systems, update OpenSSH to the fixed release (10.6p2 or the vendor equivalent) and restart sshd today, or disable password authentication until you can. Common glibc servers (Debian, Ubuntu, RHEL) are not affected. Next, check whether you run GPUStack (fix 2.2.0), FreeSWITCH (fix 1.11.3), or IBM Aspera Faspex 5 (fix 5.0.19 PL1).

This digest is based on what we checked on Nov 10 (JST): the CISA KEV catalog JSON feed, NVD, the OpenSSH release notes, the Alpine Linux announcement, the GitHub security advisories for GPUStack and FreeSWITCH, and IBM's security bulletin. Anything not stated is treated as not published. All four items were added to KEV on Nov 9 (US time), and CISA set the same due date, Nov 12, for all of them. KEV lists known ransomware campaign use as Unknown for all four.

We covered this in the Nov 6 digest, when no exploitation had been reported. The new fact is that CISA added it to KEV on Nov 9, and the NVD SSVC entry (CISA's assessment) now reads Exploitation=active. KEV describes it as an unexpected return value problem in OpenSSH on Linux that can allow authentication bypass (CWE-394), with a due date of Nov 12. Where and at what scale the exploitation is happening has not been published.

To recap, per NVD: in OpenSSH before 10.6p2 on Linux using musl libc without PAM, for some account configurations any password between 256 and 1024 characters succeeds. In plain terms, an account that should not accept a password (one whose password field is "*") can be logged into with a long arbitrary string. The severity is CVSS 3.1 8.1 (High, scored by MITRE, attack complexity High). It was reported by Özgün Kültekin of Wakefield.

According to the Alpine Linux announcement, you are affected only if all of the following are true.

- You use openssh-server (built without PAM), or openssh-server-pam with UsePAM no
- PasswordAuthentication is enabled (the OpenSSH default)
- At least one account has "*" in its password field (for example root in the Alpine base image, key-only users, directory-service users, or the alpine user in tiny-cloud images)
- At least one local account has a $5$ or $6$ password hash

Not affected: openssh-server-pam with UsePAM yes, systems with PasswordAuthentication no, locked accounts ("!"), and containers that do not run sshd. glibc-based systems such as Debian, Ubuntu, and RHEL are also outside the scope. Affected Alpine releases are 3.21 through 3.24, edge, and the unsupported 3.16 through 3.20.

The fix is OpenSSH 10.6p2 (released Nov 5). The OpenSSH team calls it a "critical security workaround" and says the root cause lies outside sshd (musl's crypt()) but sshd now works around it. Fixed Alpine openssh packages are below.

After updating, restart the running sshd; the upgrade alone does not restart it. If you cannot update yet, confirm key-based login works and then disable password authentication as a workaround. Keep your current session open while you do.

Because exploitation is confirmed, checking for a past intrusion matters. Alpine's announcement suggests the following. If you find a login you cannot explain and cannot rule out a compromise, treat the machine as compromised.

- Search /var/log/messages for "Accepted password for" entries on accounts that have no password (alpine, root, key-only users)
- Review doas usage, recently created users, recently changed files, and authorized_keys

A dedicated guide is in OpenSSH CVE-2026-123158 (sshole): how to check and fix. Official: OpenSSH release notes, Alpine announcement, fix commit, NVD

GPUStack is an open-source manager for GPU clusters and AI model serving. According to the GitHub security advisory and NVD, in versions before 2.2.0 a request whose source looks like loopback (127.0.0.1) is treated as the built-in administrator when force_auth_localhost is false, which is the default. There are two ways a remote request can look like loopback: a reverse proxy on the same host (every request then arrives from 127.0.0.1) and a client-supplied X-GPUStack-Real-IP header.

The result is unauthenticated administrative access. NVD and KEV list user and model changes, creation of persistent administrator API keys, disclosure of worker and cloud-provider secrets, and code execution through POST /v2/inference-backends/from-yaml. The severity is CVSS 3.1 9.8 (scored by GitHub; CWE-287, CWE-290, CWE-346). The advisory and NVD state that exploitation was observed in the wild against a 2.1.1 deployment.

In plain terms, anyone from outside can get in by claiming to be the administrator sitting on the machine itself. Cloud credentials can leak, so the damage from abuse can be large. All versions before 2.2.0 are affected, and the fix is 2.2.0, which removes the path that treats a loopback source as admin and hardens client-IP and forwarding-header handling.

If you cannot update immediately, the advisory lists three workarounds: set force_auth_localhost to true, strip the X-GPUStack-Real-IP header at the edge proxy, and keep the API off untrusted networks. Also check for administrator API keys or users you do not recognize; if you find any, revoke the keys and rotate worker and cloud credentials.

Official: GitHub advisory GHSA-gj9m-f8ph-pmhr, NVD

FreeSWITCH is an open-source telecom stack for building IP telephony and call systems. According to the GitHub security advisory and NVD, in 1.11.2 and earlier (before 1.11.3), an inbound SIP MESSAGE has its To user split on a plus sign, and the left side is treated as a chat protocol selector. Selecting the api protocol reaches FreeSWITCH's API executor, which can run API commands, including operating-system command sinks, with the daemon's privileges.

The impact is disclosure of configuration and credentials, arbitrary call control, and command execution. The severity is CVSS 3.1 9.8 (scored by GitHub; CWE-77, CWE-78, CWE-749). The advisory and NVD state that exploitation has been observed in the wild. Any SIP profile that accepts MESSAGE is affected by default. Even with MESSAGE authentication enabled, any registered account can exploit it, and directory entries without a password (such as the default user in the stock configuration) allow access without credentials.

The fix is 1.11.3, which rejects requests selecting the api proto with a 403 and logs them; the setting that allows it (enable-chat-api-proto) is off by default. The only listed measure that closes the path outright without updating is enable-chat=false on SIP profiles that do not need inbound chat. Enabling MESSAGE authentication, removing passwordless directory users, and setting disable_system_api_commands=true reduce risk but do not close the route.

Even if you do not run FreeSWITCH yourself, some IP phone or call-center products use it internally. Ask your integrator or the product vendor. Official: GitHub advisory GHSA-mg63-h38w-8p9p, NVD

IBM Aspera Faspex is software for transferring large files. According to IBM's security bulletin (first published Nov 7), Faspex 5 versions 5.0.0 through 5.0.19 let an authorized user craft a specific message to bypass user authorization and gain full administrative privileges. The weakness is CWE-863 (incorrect authorization). The severity is CVSS 3.1 9.8 (scored by IBM). KEV describes it as letting an authenticated user bypass authorization and escalate privileges.

One caveat: the description assumes an authorized user, but IBM's CVSS vector is scored with no privileges required (PR:N). From the published information alone, it is unclear whether it can be exploited without logging in. The safe reading is that anyone who can log in could become an administrator. IBM's bulletin lists no workaround.

The fix is to move the Linux deployment to 5.0.19 PL1, following IBM's container image patching instructions, and to verify that the faspex-core image is 5.0.19 (1ce4b13, Fix Pack: 1). If you expose Faspex to exchange files with outside partners, handle it first. The version details come from IBM's bulletin.

Official: IBM security bulletin, NVD

- Ask your IT contact whether any servers or cloud workloads use Alpine Linux (including Docker alpine images). If they run sshd, ask for the OpenSSH update and an sshd restart. For OpenWrt devices such as routers, check the vendor's update information
- Until the update is done, ask them to disable password authentication and use key authentication only
- Because exploitation is confirmed, also ask them to check affected systems for logins you cannot explain (logs, new users, authorized_keys)
- Ask whether anyone runs GPUStack, even as a trial. If so, ask for an update to 2.2.0 or later and a review of administrator API keys
- Ask your integrator whether your IP phone or call-center platform uses FreeSWITCH. If so, ask for an update to 1.11.3
- Ask whether IBM Aspera Faspex 5 is used for large file transfers. If so, ask for an update to 5.0.19 PL1
- If none of these products are in use, note that today's items do not apply to you

- OpenSSH CVE-2026-123158 (sshole): how to check and fix
- Nov 6 vulnerability digest (first report on OpenSSH)
- Nov 9 vulnerability digest
- Patch and update management guide for SMBs (2026)

- CISA: Known Exploited Vulnerabilities Catalog
- OpenSSH release notes
- Alpine Linux: openssh-server password authentication bypass
- openssh-portable: fix commit
- NVD: CVE-2026-123158
- GitHub advisory: GHSA-gj9m-f8ph-pmhr (GPUStack)
- NVD: CVE-2026-102895
- GitHub advisory: GHSA-mg63-h38w-8p9p (FreeSWITCH)
- NVD: CVE-2026-116779
- IBM: Aspera Faspex 5 security bulletin
- NVD: CVE-2026-123218