Is Your Alpine sshd Exposed to SSHole, CVE-2026-123158? A Four-Condition Check

It is a password authentication bypass in sshd on Linux systems that use the musl C library with Pluggable Authentication Modules (PAM) disabled. The OpenSSH 10.6p2 release notes of November 5 describe a "critical security workaround" for those systems and say the project considers "the root cause of this bug to be outside sshd, but it is exploitable via sshd."

Alpine Linux's advisory explains it. Without PAM, sshd hashes the attempt with crypt() and compares it to the stored field, borrowing another account's salt when the stored field is too short to hold one. That is why a second account with a real hash matters. For a password over 256 bytes, musl's crypt() returns the string * as an error, and * is exactly what Alpine stores for an account with no password. The strings match and the login succeeds. Alpine says the attack "takes one connection, works every time, and needs no retries."

Only those where all four conditions in Alpine's advisory hold.

Alpine says every release it checked is affected, 3.16 through 3.24 and edge. Ethiack says other musl systems such as OpenWrt and Buildroot may be exposed if they meet the conditions, and that glibc distributions such as Debian, Ubuntu, Fedora and RHEL are not affected. Root's default protection, PermitRootLogin prohibit-password, doesn't help if another reachable account can become root, for example through doas.

Alpine's official tiny-cloud images (the qcow2, VHD and AMI artifacts) from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. They are safe on first boot, Alpine says, but become exploitable for root once any $6$ hash appears, for example when an admin sets a console password. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package, which makes the point release the quickest key for an image inventory.

Vendor appliances are harder to see. Firmware built with Buildroot or OpenWrt may use musl, and the C library the build used is what matters. The vendor's advisory, not your scanner, settles whether a device is affected.

Containers that don't run sshd aren't affected, Alpine says. For images that do, a software bill of materials listing musl and openssh-server finds them faster than a scan; our SBOM post covers those inventories.

Upstream, OpenSSH 10.6p2. Alpine patched each branch without moving it to that release, so its fixed version numbers look old. The fixed packages are 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22 and 9.9_p2-r1 on 3.21, with fixes published back to 9.0_p1-r6 on 3.16. A rule that flags anything below 10.6p2 will keep flagging fixed Alpine hosts and bury the ones that still need work. Match on the distribution's package release instead.

The daemon is the other half. Alpine's advisory says "upgrading the package alone does not replace the running daemon." Until sshd restarts, the host still answers with the vulnerable code.

From our delivery teams: Close each SSHole ticket with two pieces of evidence, the installed package release and an sshd process start time later than the package install. A package list alone doesn't show the restart happened.

If you can't upgrade in time, Alpine's fallback is to set PasswordAuthentication no and restart sshd, after confirming key-based login works. Either step closes the hole, Alpine says.

Check the release line too. Alpine says 3.21 reached end of support on November 1, 2026 and 3.16 through 3.20 no longer get regular updates, though it published SSHole fixes for them. A host there is patched and still on unsupported software, a separate finding.

The catalog lists November 12 and sets the forensicTriage field to "Yes," so the work is a fix plus a compromise check. The required action points to Binding Operational Directive (BOD) 26-04: apply vendor mitigations, follow the directive's guidance for cloud services, or stop using the product if no mitigation exists. It adds that "stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines." Under BOD 26-04 the timeline also depends on each asset's exposure, as our KEV explainer describes, so your CISO's office decides which date governs an internal host.

Exploitation started before the listing. SecurityWeek reported on November 9 that WatchTowr and Previdian saw attacks in the wild, with Previdian counting 20 attempts from 13 IP addresses in 9 countries, first observed November 6. WatchTowr said only botnets and crypto miners had picked it up so far.

For the check itself, Alpine says to search /var/log/messages for sshd lines reading "Accepted password for" an account that has no password, then review doas use and recently created users, files and authorized keys on exposed machines. Alpine adds: "If you cannot rule out a login, treat the machine as compromised." Local logs may have rotated or been altered on a host that was entered, so search the copies in your central log store too; our OMB M-26-14 post covers the logging requirements behind them.

List every host, image and appliance that runs sshd on a musl-based system and test the four conditions; glibc hosts close out with a note of the distribution. Where all four hold, install the fixed package, restart sshd, record both and run the log search. Rebuild container images rather than patching running containers. Where an appliance vendor has no fix yet, turn off password logins or restrict SSH access, and document it.

Contractors running systems for an agency typically get their obligations through the contract. Ask the contracting officer or agency security office which timeline applies.