OpenSSH flaw lets 257-byte passwords into Alpine: fixed builds, checks

OpenSSH shipped version 10.6p2 on November 5 with what its release notes call "a critical security workaround" for Linux systems that use the musl C library with PAM turned off. On those systems an account that is supposed to refuse password logins, marked with an asterisk in /etc/shadow, can be opened with any password between 257 and 1,024 bytes long, as long as password logins are on and some other account on the machine has a real password. Alpine published fixed openssh packages the same day for every release back to 3.16, including releases it no longer supports.

Özgün Kültekin of Wakefield found the bug and wrote it up at sshhole.com. Since August 2012, musl's crypt() has returned the string * when hashing fails, and it fails on any password longer than 256 bytes. Since OpenSSH's 2016 fix for CVE-2016-6210, sshd hashes a password even for an account with no real hash, using another account's salt. So an oversized password hashes to *, the stored field is *, and the two match. OpenSSH says it considers the root cause to be "outside sshd" but has blocked it there. According to OX Security, 10.6p2 now rejects a stored hash too short to be real.

Alpine's advisory says no CVE identifier had been assigned when it was written. Alpine's security tracker and OX Security list the flaw as CVE-2026-123158.

Why it matters to IT teams

Alpine is widely used in containers and cloud environments, as OX Security notes, and its openssh-server package is built without PAM. Root on Alpine has carried a * since 3.16. On Alpine's official AWS and Azure images, the default alpine user also has a * and passwordless doas, so a login as alpine leads to root, Kültekin writes. Alpine says a single connection is enough, with no retries.

Five conditions must all hold: musl, no PAM, password authentication on (the OpenSSH default), an account whose password field is *, and a second local account that has a real password hash. A fresh box with no passwords set is not affected. Neither is anything on glibc (Debian, Ubuntu, Fedora), any server that checks passwords through PAM, Dropbear or OpenBSD.

Where to look first

Upwind, a cloud security company, swept the environments it monitors and found that package counts overstate the problem. About 98 environments shipped Alpine openssh-server, most of them images for debugging, CI or VMs in which sshd never runs. Of 471 groups of containers that did run sshd, 331 were on glibc, 38 on musl and 102 could not be classified. In Upwind's view, finding the package in a scan is a cue to investigate, not to wake someone up. That gives a working order:

1. Alpine VMs built from the official tiny-cloud images, versions 3.18.11 to 3.24.3, which come with the alpine user set to * and passwordless doas. Alpine says a freshly booted instance is safe. The risk starts once any $6$ password hash lands on the machine, say because an admin set a console password or the user-data created a user with a hashed password. Then a login as alpine leads to root. Images configured through cloud-init are not affected, because cloud-init turns password logins off.
2. Containers that actually start sshd on Alpine. An image that only carries the package is lower priority.
3. Appliances built on musl. OpenWrt ships Dropbear, which is not affected, but a router switched to OpenSSH needs the same check, Christoph Langner writes at Linux und Ich. Buildroot and Yocto firmware sits in NAS boxes, cameras and industrial controllers, rarely says what is inside, and can only be fixed by a vendor update.

The fixed Alpine builds

The list is from Alpine's advisory. The point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 carry the fixed package, and cloud images built from them include it. Release 3.21 left support on November 1, and 3.16 to 3.20 no longer get regular updates, yet all of them got this fix. Upwind also notes that openssh-server-pam is exposed only if UsePAM no is set.

More OpenSSH releases are coming

The OpenSSH team first said this in the 10.6 release notes on October 6 and repeated it in 10.6p2: many of the bug reports it now receives are found with AI, and in a number of cases a bug found by AI tools was later found again by another researcher. That, the team says, suggests attackers who never report bugs are likely able to find them too, so OpenSSH will "for now" ship more frequent releases instead of batching fixes. Kültekin found this one by running about 17,600 odd logins against 12 sshd builds with AI agents. Teams that bake sshd into golden images should plan for more point releases between image refreshes.

What IT teams should do

• Upgrade with apk upgrade -U -a and then restart the service with rc-service sshd restart. OX and Upwind both warn that upgrading the package leaves the old daemon running.
• Rebuild container and VM images from a fixed base and redeploy. Patching a running container does not fix the image it came from.
• If you cannot upgrade yet, put PasswordAuthentication no in a file under /etc/ssh/sshd_config.d/ and restart sshd. Alpine notes that its default config reads that folder only from 3.19 on, so on 3.16 to 3.18 change /etc/ssh/sshd_config itself. Confirm key login works first.
• Check the setting sshd is really using with sshd -T | grep -i passwordauthentication. It should print passwordauthentication no.
• Lock unused accounts with ! instead of *, which this bug cannot open, and take passwordless doas away from the alpine user.
• Search /var/log/messages for Accepted password on root, alpine or any key-only user. That line should never appear for a * account. If it does, treat the host as compromised and review doas use, new users and changes to authorized_keys.
• Do not run checker or exploit scripts from social media. Use the OpenSSH release and your distribution's packages.

Sources: sshhole.com, OpenSSH 10.6p2 release notes, Alpine Linux advisory, Alpine Security Tracker, BleepingComputer, OX Security, Upwind, Linux und Ich, Hacker News.