Alpine and Other musl Linux: A 257-Byte Password Can Log Into SSH Accounts With No Password Set

Nobody needs to guess a password to log in to an affected Alpine server over SSH. They need to send one that is too long. On 5 November the OpenSSH project released 10.6p2 with what its release notes call a critical security workaround for Linux systems that use the musl C library and run sshd without PAM. A password between 257 and 1,024 bytes can be accepted for an account that has no password set, which on Alpine includes the default root account.

This is not a data-breach story, and nothing here says anyone has been compromised. It matters to this blog because SSH is where many teams keep their deepest secrets: deploy keys, database credentials and cloud tokens sit on the hosts people reach this way. If a server like that was exposed with password logins on, the question after patching is what it held.

What is confirmed

The fix and the scope. The OpenSSH 10.6p2 release notes describe a password authentication bypass in sshd that affects some Linux systems built and run with PAM disabled, and say the root cause is outside sshd although it can be exploited through it. The release notes say it concerns Linux with musl libc and PAM disabled.
Who found it. The notes credit the report to Özgün Kültekin of Wakefield.
Alpine fixed packages. Alpine's security tracker lists fixed openssh packages for its supported branches, including 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24 and 10.2_p1-r1 on 3.23. The tracker entry for CVE-2026-123158 carries no description of its own.

How it works, according to OX Security

OX Security's analysis, published the same day, explains three decisions that combine. The musl implementation of the password-hashing function refuses inputs longer than 256 bytes and, on failure, returns the string *. OpenSSH, since a 2016 change meant to make username enumeration harder, hashes using settings taken from another account when the target has no valid hash. And on Alpine, the default root account is stored with * as its password field. A password over the limit therefore produces *, which is compared with the stored * and accepted.

According to the same analysis, an attack needs all of the following: sshd on a musl system, PAM not in use (Alpine's OpenSSH server does not use it by default), password logins enabled (the default), an account with no password set, and at least one other account with a real password. A single attempt can succeed. Other press reports describe the conditions slightly differently, so test your own hosts rather than rely on a checklist.

Affected in principle are musl-based systems: Alpine, and the OpenWrt, Buildroot and Yocto builds that appear in routers and embedded devices. Containers matter only if they run an OpenSSH server. OX lists as not affected Debian, Ubuntu and other glibc systems, PAM-based setups, hosts with PasswordAuthentication no, accounts locked with !, Dropbear and OpenBSD's SSH.

What is not established

Exploitation. OX Security and the press coverage we saw report no exploitation in the wild. We could not verify that independently, and absence of a report is not absence of attacks.
Counts. How many internet-facing hosts are reachable and vulnerable. We have seen no credible figure.
Public exploit code. We did not find a verified one. OX warns against running unverified exploit or scanner scripts from public repositories or social media, which is sensible, since they are a ready-made way to infect yourself.
Whether musl will change. The OpenSSH change works around the behaviour rather than altering the C library.

What to do

Find your musl hosts. Alpine servers and VMs, Alpine-based container images that run sshd, and routers or appliances running OpenWrt or an embedded build. If you cannot list them, start with the ones reachable from the internet.
Update and restart. On Alpine, upgrade the packages and restart sshd, since installing the new package does not replace the running daemon. For images, rebuild from a fixed base and redeploy rather than patching running containers in place.
If you cannot update yet, turn off password logins. Confirm that key-based login works first, then set PasswordAuthentication no and restart sshd. This is a good setting anyway.
Close SSH to the internet where you can. Put it behind a VPN or an allow-list. Even a fixed bug is a reason not to expose a management port to everyone.
Check the logs for accepted password logins on accounts that should not have a password. OX points to Accepted password for entries for root, the default Alpine user and key-only users. If you find any, treat the machine as compromised.
If a host was exposed with password logins on, rotate what it held. That means SSH host and user keys, deploy keys, environment variables, database and API credentials, and any tokens stored in files on the machine. Rotate first the ones that reach other systems.
Remove empty-password accounts. Lock service accounts properly, and do not rely on password logins to protect a root account.

The handover after a rotation

A rotation produces new keys and passwords that have to reach the people who deploy them, often late in the day and in a hurry. That is when a credential ends up in a chat, a ticket or a shared document that outlives the incident. Send each new value once, to the one person who needs it, over a channel that does not keep it. Do not put private keys in a repository on the way to the server.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a patching, scanning or access-management product. It cannot find your Alpine hosts, update OpenSSH, disable password logins or read your logs. Use your package manager and configuration management for that, and a one-time link for the moment one person gives another a credential.