CVE-2026-123158 (*sshole): Alpine OpenSSH Password Bypass

• You run sshd on Alpine with password logins on

  The default openssh-server package, or openssh-server-pam with UsePAM no

  Act now

  Update openssh and restart sshd today. If an account has a real password hash, every key-only account on that host is open to anyone who can reach port 22. What to do

• You launched VMs from official Alpine tiny-cloud images

  qcow2, VHD and AMI images from 3.18.11 through 3.24.3

  Act now

  These ship an alpine user with no password and passwordless doas. Once any password hash exists on the VM, the attacker gets root. Update every running instance; a new image does not fix old ones. Cloud images

• You build devices or images on musl with OpenSSH

  Buildroot, Yocto, OpenWrt with OpenSSH installed, custom images

  Update needed

  The same conditions apply outside Alpine, and no distribution list covers you. Build OpenSSH 10.6p2 or set PasswordAuthentication no. Beyond Alpine

• You run Alpine containers that do not run sshd

  Most Alpine-based application images

  Low risk

  Not affected, per Alpine. If an image installs openssh-server, rebuild it on the fixed package or remove sshd.

• Your servers run Debian, Ubuntu, RHEL or another glibc distribution

  Also macOS, Windows, OpenBSD and any sshd that checks passwords through PAM

  Protected

  Not affected, according to OpenSSH. The bug needs musl, the C library Alpine uses, and sshd checking passwords without PAM.

• You already set PasswordAuthentication no

  Including hosts configured by cloud-init, which sets it for you

  Protected

  Not affected. Update anyway, and confirm the setting is in force with sshd -T rather than trusting the config file.

A host is exploitable when all four of these are true, according to Alpine:

• sshd checks passwords without PAM. Alpine’s openssh-server package is built that way; openssh-server-pam is affected only with UsePAM no.
• PasswordAuthentication is yes, which is the OpenSSH default.
• An account that can log in has * as its password field: a key-only user created with adduser and no password, the alpine user on tiny-cloud images, or a directory user from nslcd, winbind or sssd through musl-nscd.
• At least one other local account has a $5$ or $6$ password hash. One is enough to expose every passwordless account.

Root ships as root:* on Alpine, but OpenSSH’s default PermitRootLogin prohibit-password blocks password logins to it. That stops helping as soon as the attacker lands on another account that can become root, for example through doas. Accounts locked with ! are not affected.

1. 01

   Find every sshd running on musl

   Alpine servers and VMs, but also appliances, routers and embedded boards built with Buildroot or Yocto, and any container image that installs openssh-server. How to check
2. 02

   Update openssh and restart sshd

   Upgrading the package does not replace the running daemon. Until sshd restarts, the host is still exposed. Fixed versions
3. 03

   Turn off password logins where you cannot update

   PasswordAuthentication no closes the hole on its own. Confirm key login works first. The commands
4. 04

   Look for password logins to passwordless accounts

   Any such login in the logs means the host was broken into. What to look for
5. 05

   Record the decisions

   Note which hosts met the conditions, what you changed and when, and what the log review found. For compliance

apk upgrade -U -a
apk info -v | grep '^openssh'     # compare with the table above
rc-service sshd restart           # the upgrade does not restart sshd

Stable branches keep their older OpenSSH version and carry a patch for the same problem, so do not look for 10.6 there. Compare the package version with the table instead. Source from Alpine’s advisory.

Cloud images

Alpine’s official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 create an alpine user with a * password field and passwordless doas. They are safe on first boot, because no account has a password hash yet. They become exploitable once one does, for example when an admin sets a console password or user-data adds a user with hashed_passwd. The attacker then logs in as alpine and becomes root.

Images built from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fixed package. Instances already running from older images keep the old package until you update them. Images configured through cloud-init are not affected, because cloud-init writes PasswordAuthentication no.

Beyond Alpine

The CVE record covers OpenSSH before 10.6p2 on any Linux system that uses musl without PAM. The researcher names OpenWrt, Buildroot and Yocto. OpenWrt uses Dropbear for SSH by default, and Dropbear is not affected, per musl’s maintainer, so OpenWrt matters only where someone installed the OpenSSH server. Alpine is the only distribution with a published fix list as of 5 November. For other musl builds, move to OpenSSH 10.6p2 or turn off password logins.

cat /etc/alpine-release 2>/dev/null || ldd "$(command -v sshd)" | grep -i musl
apk info -v 2>/dev/null | grep '^openssh-server'
sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '
awk -F: '$2=="*" {print $1}' /etc/shadow              # accounts with no password
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow     # accounts with a $5$ or $6$ hash

• If the first line prints nothing, sshd is not on musl and this flaw does not apply.
• If sshd -T prints passwordauthentication yes and either no usepam line or usepam no, the host is exposed until it runs the fixed package. Builds without PAM do not print a usepam line at all.
• If both awk lines print names, the accounts from the first are the ones an attacker can log in as.
• sshd -T shows global settings. A Match block can turn password logins back on for some users or addresses, so read the config file too.

From outside, a scanner can only tell you that sshd offers password logins. It cannot see the C library or the shadow file. Use it to find candidates, then check each on the host.

Before you start, confirm that SSH key login works, and keep your current session open until a new login succeeds. These are Alpine’s commands. The drop-in file is read from Alpine 3.19 onward; the sed line covers older releases by changing every PasswordAuthentication yes in the main file to no, including inside Match blocks, and adding the setting at the top. It keeps the original as 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

rm /etc/ssh/sshd_config.d/00-no-passwords.conf
cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sshd -t && rc-service sshd restart

If nobody needs password logins over SSH, leave them off after you update. Key-only SSH is the safer default, and it would have made this flaw irrelevant.

Locking a passwordless account with ! also blocks the attack for that account, but on builds without PAM it blocks key logins as well. Do not use it on accounts you log in to.

grep 'sshd.*Accepted password for' /var/log/messages*
awk -F: '$2=="*" {print $1}' /etc/shadow     # compare the names against these
grep doas /var/log/messages*                 # doas use after a suspicious login

• The tell. An Accepted password for line naming alpine, root or any key-only user cannot happen legitimately. Alpine logs sshd to /var/log/messages by default; check your central log store too, since local logs can be wiped after a break-in.
• What else to review. doas use, new users, changed files and new entries in authorized_keys on exposed machines, per Alpine.
• If you find one. Alpine’s advice is to treat the machine as compromised if you cannot rule out a login. Rebuild it rather than clean it, and rotate any secrets it held.
• In the wild. No attacks had been reported as of 5 November 2026, and the CVE is not in CISA’s KEV catalog. CISA rates exploitation as proof of concept, not active. The researcher notes the bug has been present since 2016, so absence of reports is not evidence nobody used it.

Without PAM, sshd checks a password itself. It hashes the attempt with crypt(), the C library function that turns a password into its stored form, and compares the result with the field in /etc/shadow. A real hash looks like $6$salt$…. An account with no password has just *, which nothing should ever match.

Since a 2016 fix for a timing flaw, sshd does not reject those accounts instantly. It hashes the attempt anyway, borrowing another account’s salt, so attackers cannot tell real usernames from fake ones by response time. That is why a $5$ or $6$ hash must exist somewhere on the host.

musl’s crypt() returns the string * when it fails, and its SHA-256 and SHA-512 code refuses passwords over 256 bytes. So a password of 257 bytes or more “hashes” to *, which equals the stored *, and sshd accepts the login. glibc returns a different failure value, and PAM never calls crypt() for a * account, which is why other systems are unaffected.

OpenSSH 10.6p2 makes sshd refuse a match when the stored field is shorter than four characters. The release notes call it a workaround for a root cause outside sshd and credit Özgün Kültekin of Wakefield, whose write-up says he found it by running about 17,600 unusual logins against sshd builds for glibc and musl, with and without PAM, using AI agents.

NVD has not published its own analysis. Scanners that read NVD alone may not flag this yet, and none can see the account conditions from the network.

1. 2012-08-09

   2012-08-09

   musl changes crypt() to return the string “*” instead of NULL when it fails, so callers that never check for errors see a wrong password rather than crash.

   musl commit b3c4cc12

2. 2012-08-29

   2012-08-29

   musl caps SHA-crypt keys at 256 bytes to stop very long passwords tying up the CPU. Longer keys now fail, and failure returns “*”.

   musl commit 88bf5a8a

3. 2016-07-15

   2016-07-15

   To fix a username-guessing timing flaw (CVE-2016-6210), sshd starts hashing password attempts with another account’s salt when the target account has no real hash.

   openssh-commits

4. 2022-05-23

   2022-05-23

   Alpine 3.16 ships root as root:* (no password) in the base image, the earliest release Alpine lists as affected.

   Alpine advisory

5. 2026-11-04

   2026-11-04

   Özgün Kültekin of Wakefield reports the bypass to the OpenSSH project, according to heise.

   heise online

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”.

   LWN

7. 2026-11-05

   Alpine publishes its advisory and fixed openssh packages for edge and every branch back to 3.16, plus point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

   Alpine advisory

8. 2026-11-05 · 15:07 UTC

   musl maintainer Rich Felker posts an advisory telling users who cannot upgrade to set PasswordAuthentication no.

   musl mailing list

9. 2026-11-05 · 15:46 UTC

   MITRE publishes CVE-2026-123158, scored CVSS 3.1 8.1. NVD has not yet published its own analysis.

   CVE record

10. 2026-11-05 · 17:18 UTC

    CISA adds its assessment to the CVE record: proof-of-concept exploitation, not automatable, total technical impact. It tags the sshhole.com write-up as an exploit reference.

    CVE record

Evidence to keep: the date you assessed it, the list of musl hosts and images with their openssh versions and sshd -T output, the date each was updated and sshd restarted, the PasswordAuthentication change, and the result of the log review. If a host cannot be updated within your patch policy’s deadline, record the exception and the compensating control.

For how these controls work day to day, see our guides to ISO 27001 vulnerability management, SOC 2 vulnerability management and ISO 27001 change management.

• Alpine Linux: Security advisory: openssh-server password authentication bypassConditions, fixed packages per branch, the PasswordAuthentication workaround, cloud images and log checks.
• OpenSSH 10.6p2 release notesThe sshd workaround and credit to Özgün Kültekin of Wakefield.
• CVE-2026-123158, CVE record (MITRE)Description, affected versions, the CVSS 3.1 8.1 score and CISA’s SSVC assessment.
• NVD entry for CVE-2026-123158Received by NVD and not yet analysed as of 5 November 2026.
• LWN: Critical security vulnerability affects OpenSSH on AlpineDamien Miller’s announcement and the scope statement.
• Rich Felker: Advisory for OpenSSH+musl usersmusl’s position on the root cause, and that Dropbear is unaffected.
• Özgün Kültekin: *sshole write-upThe researcher’s history of the bug and the musl platforms to check.
• heise online: OpenSSH and Alpine Linux warn of severe but niche bugWhen the report reached OpenSSH, and why the release was rushed.
• OpenWrt: Dropbear configurationOpenWrt’s default SSH server, which is not OpenSSH.
• CISA Known Exploited Vulnerabilities catalogNo entry for CVE-2026-123158 as of 5 November 2026.