sshhole: Alpine Linux OpenSSH password authentication bypass on musl without PAM (CVE-2026-123158)

• You run sshd on Alpine with password logins on

  openssh-server, or openssh-server-pam with UsePAM no. PasswordAuthentication defaults to yes

  Act now

  Update openssh and restart sshd today, or turn password logins off now. Steps

• You launched an official Alpine tiny-cloud image

  AMI, VHD or qcow2 from 3.18.11 through 3.24.3

  Act now

  The alpine user has passwordless doas, so this can be root. Details

• You build images or firmware on musl with OpenSSH

  Alpine-based appliances, OpenWrt, Buildroot or Yocto builds

  Update needed

  Ship OpenSSH 10.6p2 or a backport, and check whether your build uses PAM. Other musl systems

• Alpine containers that do not run sshd

  Typical application images built FROM alpine

  Low risk

  Not affected. Update on your normal schedule.

• PAM in use, or PasswordAuthentication no

  openssh-server-pam with UsePAM yes; key-only sshd

  Protected

  Not affected. sshd never reaches the vulnerable crypt() comparison.

• glibc distributions, BSDs, Dropbear

  Debian, Ubuntu, RHEL, Fedora, SUSE, OpenBSD, macOS

  Protected

  Not affected, per OpenSSH and musl.

Accounts locked with ! are not affected. Cloud images provisioned with cloud-init are not affected because cloud-init writes PasswordAuthentication no.

1. 01

   Check exposure on each Alpine host

   Run as root. If passwordauthentication is yes, usepam is no or missing (a build without PAM prints no such line), and both awk commands print names, the host is exploitable.

   ShellCopy

   apk info -vv | grep -E '^openssh-server'          # which sshd package and version
   sshd -T | grep -Ei '^(passwordauthentication|usepam|permitrootlogin)'
   awk -F: '$2 == "*" {print "no password: " $1}' /etc/shadow
   awk -F: '$2 ~ /^\$[56]\$/ {print "salt donor:  " $1}' /etc/shadow

2. 02

   Update openssh and restart sshd

   Internet-facing hosts first. Compare the result with the fixed version for your branch.

   ShellCopy

   apk upgrade -U -a
   rc-service sshd restart
   apk info -v openssh-server   # compare with the fixed version for your branch

3. 03

   Cannot update right now? Turn password logins off

   This closes the hole on its own. Commands
4. 04

   Rebuild images that run sshd

   Container images, golden VM images and appliance builds keep the old package until rebuilt. New instances from an old image are vulnerable on first boot if they meet the conditions.
5. 05

   Check logs on hosts that were exposed

   Look for password logins to accounts that have no password. How

Stable branches carry a backported patch under their existing OpenSSH version, so a 3.24 host showing 10.3_p1 is fixed from -r2. Do not judge exposure by the upstream version number alone.

These are Alpine's published commands. The drop-in file is read from Alpine 3.19 onward; the sed line covers older releases by flipping every PasswordAuthentication yes in the main config, including inside Match blocks, and saves the original as /etc/ssh/sshd_config.bak.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # expect: passwordauthentication no

• A Match block that sets PasswordAuthentication yes for some users or addresses keeps those logins exposed. Test with sshd -T -C user=NAME,addr=IP,host=HOST.
• Setting a real password on the * accounts or locking them with ! also blocks the attack, but without PAM ! disables key logins for that account too.
• Restricting port 22 to known networks reduces exposure but does not fix the bug.

Official tiny-cloud images (AMI, Azure VHD and qcow2) from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot because no account has a $6$ hash to borrow a salt from. They become exploitable as soon as one exists, for example after an admin sets a console password or user-data adds a user with hashed_passwd. An attacker then logs in as alpine and runs doas to become root.

Images from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Every instance already running from an older image needs the update or the mitigation, because a patched image does not change a running VM.

Without PAM, sshd checks a password by hashing the attempt with crypt() and comparing the result to the stored password field with strcmp(). A * in that field has never been a valid hash, so traditionally no password could match it.

• musl returns * on failure. Since 2012, musl's crypt() returns the string * instead of NULL when it fails, so careless callers see a wrong password rather than crash.
• Long keys fail. musl's SHA-256 and SHA-512 crypt refuse keys over 256 bytes to avoid denial of service, and so return *.
• sshd borrows a salt. Since the fix for CVE-2016-6210, sshd hashes attempts for accounts without a usable hash using another account's $5$ or $6$ salt, so rejecting them takes as long as a real check.
• The match. A password of 257 to 1,024 bytes (sshd's own upper limit) makes crypt() return *, which equals the stored *, and sshd accepts the login.

Alpine made the condition common in 3.16, when it switched root from ! to * because ! without PAM also blocks key logins. With PAM, the module never runs this comparison, which is why most distributions never saw it.

The OpenSSH fix rejects any stored password field shorter than a minimum hash length before comparing, and copies the shadow entry instead of pointing into libc's static buffer. OpenSSH says it considers the root cause to be outside sshd. musl's Rich Felker says it is "not a bug in musl just an erroneous use by the caller", but expects musl to change the failure behavior in its next release cycle.

The musl advisory covers every OpenSSH before 10.6p2 on musl with UsePAM no and password logins on. The reporter names OpenWrt, Buildroot and Yocto as musl environments to check. Most of these ship Dropbear by default, which is not affected, but images that add OpenSSH without PAM are. If you maintain such a build, move to 10.6p2 or backport the fix commit, and default to PasswordAuthentication no.

1. Password logins to accounts without a password

Search syslog for Accepted password for lines naming alpine, root or any account whose shadow field is *. Any such line is suspicious, because those accounts have no password to accept.

grep 'sshd.*Accepted password for' /var/log/messages*
awk -F: '$2 == "*" {print $1}' /etc/shadow   # compare against the names above

2. What happened after the login

Review doas use, new users, changes to authorized_keys files and recently modified files on exposed machines. Attackers who get in this way will likely add a key so they no longer depend on the bug.

Alpine's advice: if you cannot rule out a login, treat the machine as compromised. Rebuild it on fixed packages and rotate every credential and key it held.

1. 2012-08-09

   2012-08-09

   musl changes crypt() to return the string * on failure instead of NULL, so callers that never check for NULL do not crash.

   musl b3c4cc12

2. 2012-08-29

   2012-08-29

   musl adds SHA-512 crypt with a 256-byte key limit to stop denial of service from huge passwords. Longer keys fail, and so return *.

   musl 88bf5a8a

3. 2016-07-15

   2016-07-15

   To fix the user enumeration timing leak CVE-2016-6210, sshd starts hashing attempts for accounts without a usable hash using another account's salt.

   openssh-commits

4. 2022-05-23

   2022-05-23

   Alpine 3.16 ships root as root:* instead of root:!, because ! without PAM also blocks SSH key logins.

   aports fbe926af

5. 2026-11-04

   2026-11-04

   Özgün Kültekin of Wakefield reports the bypass to OpenSSH after differential testing of sshd builds against glibc and musl, with and without PAM.

   sshhole.com

6. 2026-11-05

   2026-11-05

   OpenSSH releases portable 10.6p2. Damien Miller tells operators of musl systems without PAM to set PasswordAuthentication no or disable SSH immediately.

   OpenSSH 10.6p2

7. 2026-11-05

   Alpine publishes its advisory and fixed openssh packages for 3.16 through 3.24 and edge.

   Alpine advisory

8. 2026-11-0515:07 UTC

   musl maintainer Rich Felker posts an advisory for OpenSSH and musl users, says Dropbear is not affected, and expects to change the crypt() failure behavior in the next release cycle.

   musl mailing list

9. 2026-11-0515:46 UTC

   MITRE publishes CVE-2026-123158, CVSS 3.1 8.1, linking the fix commit and two public reproduction labs.

   CVE record

10. 2026-11-0517:12 UTC

    CISA adds its assessment to the record: proof of concept public, not automatable, total technical impact.

    CISA ADP

• CVE-2026-123158 recordMITRE: description, affected versions, CVSS 3.1 vector, CWE-394 and CISA's SSVC assessment.
• Alpine Linux: openssh-server password authentication bypassAffected configurations, fixed package versions, cloud image exposure, mitigation and detection.
• OpenSSH 10.6p2 release notesThe security workaround in sshd and credit to Özgün Kültekin of Wakefield.
• OpenSSH commit "avoid password authn bypass"Adds a minimum stored hash length check and stops sshd sharing libc's static shadow buffer.
• Damien Miller's announcementWho is and is not affected, the UsePAM no clarification, and why the release skipped an embargo.
• musl: Advisory for OpenSSH+musl usersRich Felker's notice, the Dropbear statement and planned crypt() changes.
• sshhole.comThe reporter's write-up with the history of each contributing change and an in-browser demo.
• LWN: Critical security vulnerability affects OpenSSH on AlpineSummary with Damien Miller's statement.
• sshhole-labPublic reproduction environment linked from the CVE record. Test only on systems you own.
• sshhole-reproA second public reproduction linked from the CVE record.
• NVD: CVE-2026-123158NIST entry. Analysis pending at the time of writing.
• CISA Known Exploited Vulnerabilities catalogCVE-2026-123158 not listed as of 5 November 2026.
• CVE-2016-6210The 2016 sshd user enumeration flaw whose fix introduced salt borrowing.