Shar z

Security Engineer, Nine-Security

10 November 2026 (UTC+8)

On some Linux systems, a password that should never work is enough to walk through the SSH front door. That is why this week's CISA Known Exploited Vulnerabilities (KEV) update deserves immediate attention from defenders, not only U.S. federal agencies.

What happened

On 9 November 2026, the U.S. Cybersecurity and Infrastructure Security Agency added four vulnerabilities to the KEV catalog, citing evidence of active exploitation:

  • CVE-2026-123158 (SSHole, CVSS 8.1): an authentication bypass in OpenBSD OpenSSH on Linux when musl libc is used and PAM is disabled.
  • CVE-2026-102895 (CVSS 9.8): improper authentication in GPUStack that can grant unauthenticated administrative access and lead to code execution.
  • CVE-2026-116779 (CVSS 9.8): a code-injection flaw in SignalWire FreeSWITCH that can disclose credentials, take over calls, and run commands.
  • CVE-2026-123218 (CVSS 9.8): an incorrect-authorization issue in IBM Aspera Faspex that can allow an authenticated user to obtain full administrative privileges.

Federal Civilian Executive Branch agencies must remediate these issues by 12 November 2026. CISA also flags all four for forensic triage under Binding Operational Directive 26-04: check whether a system was already compromised before applying the patch. Known ransomware use is listed as "Unknown." CISA encourages every organization to prioritize KEV items.

SSHole has the most public exploitation detail. OpenSSH released Portable OpenSSH 10.6p2 on 5 November 2026 as a "critical security workaround," and public exploit code appeared the same day. GreyNoise recorded the first successful exploitation of a vulnerable sensor at 00:46 UTC on 7 November 2026 (08:46, UTC+8) and, as of 10 November (07:10 UTC; 15:10, UTC+8), reported 18 confirmed post-exploitation chains from six attacker IPs, figures also cited by The Hacker News. SecurityWeek on 9 November quoted Previdian as having seen 20 attempts from 13 unique IPs between 6 and 8 November; The Hacker News later cited 22 attempts from 14 addresses. watchTowr has reported botnet and cryptocurrency-miner use. These observations come largely from honeypots and sensors, not a census of every victim. JPCERT/CC said on 9 November it had not confirmed compromises at organizations in Japan at the time of writing.

Who is affected

SSHole is not a universal OpenSSH bug. According to Alpine Linux, a host is exposed only when it runs musl libc (Alpine, and commonly OpenWrt, Buildroot, and Yocto); OpenSSH is built or configured without PAM (Alpine's default openssh-server package is in this category; openssh-server-pam with UsePAM yes is not); PasswordAuthentication is yes; at least one account has * in the /etc/shadow password field, typical for key-only users, many directory-service accounts, Alpine's root entry, and the alpine user on official tiny-cloud images; and at least one local account has a $5$ or $6$ hash so sshd can borrow a salt.

glibc-based distributions such as Debian, Ubuntu, and Fedora are outside this path, as are systems that already disable password logins, locked accounts whose shadow field is !, and containers that do not run sshd. Alpine notes that the default PermitRootLogin prohibit-password setting protects root itself, but not if another reachable account can escalate with doas. Official tiny-cloud images become exploitable once any $6$ hash is introduced, for example when an administrator sets a console password. Alpine says every release it checked, from 3.16 through 3.24 and edge, was affected.

GPUStack before 2.2.0 is at risk, especially behind a same-host reverse proxy. FreeSWITCH 1.11.2 and earlier are affected on SIP profiles that accept inbound MESSAGE, which the project says is the default. IBM says Aspera Faspex 5.0.0 through 5.0.19 is affected.

Technical details

When sshd is built without PAM, it verifies a password by hashing the attempt with crypt() and comparing the result with the stored field. For an account whose stored field is a bare * and therefore has no salt, sshd borrows a salt from another account. musl's crypt() treats a key longer than 256 bytes as an error and returns *. That error value is exactly what a no-password account stores, so the comparison succeeds. Alpine says an attacker who can reach the SSH port and who knows such a username can send a password of 257 to 1024 bytes and log in in a single connection. OpenSSH's release notes say the root cause sits outside sshd, but the bypass is exploitable through it. The issue was reported by Özgün Kültekin of Wakefield.

GreyNoise's post-exploitation notes, consistent with The Hacker News and Ars Technica, include reconnaissance, queries to cloud metadata services, attempts to read password hashes and root SSH keys (often via doas), and changes to authorized_keys. In at least one case, operators dropped a Python implant called TAC Agent (/opt/py3/tac_agent.py; SHA-256 55e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2a) that beacons to https://tac.vpnla.org with User-Agent TAC-Agent/1.0. On the sensor where enrollment was attempted, GreyNoise says the agent never joined its C2. Related artifacts include /etc/init.d/tac-agent. Successful exploitation on GreyNoise sensors continued at least through 00:58 UTC on 10 November 2026 (08:58, UTC+8).

The 31 July 2026 GPUStack advisory says versions before 2.2.0 can treat a request as loopback — and therefore as the built-in administrator — when a same-host reverse proxy makes the TCP peer 127.0.0.1, or when a client forges the X-GPUStack-Real-IP header. That can yield unauthenticated admin access, persistent admin API keys, disclosure of secrets, and code execution through POST /v2/inference-backends/from-yaml. Maintainers said exploitation was observed against a 2.1.1 deployment. The October 2026 FreeSWITCH advisory says an inbound SIP MESSAGE can select the api chat protocol and run API commands, including operating-system commands, with the privileges of the FreeSWITCH process. The path is available on default profiles unless enable-chat=false is set, and the project says exploitation has been observed. Public detail on those campaigns is thinner than for SSHole. IBM published its Faspex bulletin on 7 November 2026 and listed no workaround.

Detection and mitigation

Treat internet-facing musl SSH, GPUStack APIs, FreeSWITCH SIP, and Aspera Faspex as a same-week priority. Patch first, then hunt.

For SSHole, upgrade to OpenSSH 10.6p2 or your distribution's backport, then restart sshd. Alpine is explicit: upgrading the package does not replace a running daemon. Fixed packages exist from edge back through 3.16 (for example, 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24). If you cannot patch immediately, set PasswordAuthentication no and restart sshd after confirming that key-based login works and keeping the current session open. Hunt in /var/log/messages or the equivalent for Accepted password for on accounts that should never accept a password, such as alpine, root, and other key-only users. Review doas use, new users, unexpected files, and authorized_keys changes. Look for TAC Agent indicators (the hash and path above, tac.vpnla.org, TAC-Agent/1.0, and /etc/init.d/tac-agent) and for unexpected outbound access to cloud metadata endpoints. If you cannot rule out a successful password login, treat the host as compromised.

Upgrade GPUStack to 2.2.0 or later; until then set force_auth_localhost=true, strip client-supplied X-GPUStack-Real-IP at the edge, and review admin API keys, custom backends, and cloud secrets. Upgrade FreeSWITCH to 1.11.3 or later; until then set enable-chat=false on profiles that do not need inbound SIP chat, and remove directory users that have neither a password nor an a1-hash. Upgrade Linux Faspex deployments to 5.0.19 PL1 and confirm the faspex-core image is 5.0.19 (1ce4b13, Fix Pack 1). Alpine hosts, OpenWrt appliances, container nodes, CI runners, and AI or telephony stacks are easy to miss if vulnerability management only tracks mainstream Linux servers. CISA's due date is 12 November 2026. Organizations outside the U.S. federal scope should not wait either.

Sources