On 5 November OpenSSH shipped 10.6p2 and Alpine Linux published an advisory the same day. The bug has since been assigned CVE-2026-123158 and has picked up a nickname. The mechanism takes one paragraph to explain, which is the first thing worth noticing about it.

When sshd is built without PAM, it checks a password by hashing the attempt with crypt() and comparing the result to the stored field in the shadow file. musl's crypt() returns the single character asterisk as an error value when the key it is given is longer than 256 bytes. And a single asterisk is exactly what the stored field contains for every account that has no password set.

So a password that is long enough hashes to an asterisk, the asterisk matches the asterisk, and sshd lets you in.

The attacker sends between 257 and 1024 bytes. Two preconditions: the name of an account whose password field is an asterisk, and at least one other account on the machine with a real hash, because sshd needs a genuine hash present to borrow a salt from. Alpine's advisory puts it plainly: one user with a password is enough to expose all the locked ones.

Root is usually an account with an asterisk.

The part in Alpine's advisory that nobody quoted

Most coverage stopped at "Alpine is affected, patch it". Alpine's own advisory goes further, in a bullet that deserves to be read twice.

The official tiny-cloud images from 3.18.11 through 3.24.3 ship an account named alpine whose password field is an asterisk, and that account has passwordless doas.

Alpine's words for what follows: "They are safe on first boot. They become exploitable as soon as any 6 type hash exists on the machine."

Read that as an attack. The distribution's own cloud image arrives with half the precondition already satisfied. The first time anybody on that box sets a password for anything, the other half arrives. And the account the bypass hands you is not an unprivileged one. It can become root without being asked for a password.

That is the difference between a bug that gives you a shell and a bug that gives you the machine.

Nobody has fixed the actual bug

OpenSSH's release note is careful, and the care is the story. The fix "avoid[s] password authentication bypass that is exploitable through sshd" and then adds:

"We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there."

That is a maintainer saying, as politely as the format allows, that this is somebody else's bug. OpenSSH's change rejects any stored password field shorter than four characters, which closes the path through sshd and does nothing about the cause.

The cause is a library choosing to signal an error by returning a string that is also a valid stored value. We read musl's commit log. The most recent commit is dated 14 October 2026, three weeks before the advisory, and it has nothing to do with crypt(). There is no musl advisory and no musl fix.

So the position today is that OpenSSH worked around somebody else's bug, Alpine shipped the workaround, and the convention that caused it is untouched. Any other program on a musl system that compares crypt() output against a stored field has the same bug this afternoon, and nobody has gone looking.

The flaw was reported by Ozgun Kultekin of Wakefield.

What to do, in the right order

Alpine's advisory is unusually good on this, including a step people will skip.

  • Update and then restart sshd. Upgrading the package does not replace the running daemon. The patched binary is on disk and the vulnerable one is still serving connections until you restart it.
  • Fixed packages exist for every branch Alpine checked, 3.21 through 3.24 and edge, and for the older 3.16 to 3.20 branches that no longer get regular updates.
  • If you cannot update now, set password authentication to no and restart.
  • You are not affected if you use the PAM build with PAM enabled, if password authentication is already off, or if the container does not run sshd at all. That last one covers most Docker users.

The Hacker News reported on 6 November that the flaw was being attacked within hours of disclosure, with root obtained on a honeypot. That is reporting rather than a primary incident report, and it is consistent with what the bug costs to try, which is one long string.

The thing to take away

Alpine is the default base image for an enormous amount of containerised software, chosen precisely because it is small. Small means musl instead of glibc. That trade has been made millions of times by people who were choosing an image size and were not choosing a libc, and this is the first week it has cost anything visible.

It will not be the last, because the cause is still there.

What is not established

  • Whether musl considers this its bug. We found no statement either way. An absent commit is not a refusal.
  • Whether Dropbear, OpenWrt, Buildroot or Yocto builds on musl are affected. One secondary source reports that Dropbear's maintainer has ruled Dropbear out, which we did not confirm at source.
  • Whether the honeypot report describes a real campaign or a single opportunistic scan. The reporting does not say.
  • How many deployed tiny-cloud instances actually have a real hash on them. Alpine describes the condition, not its prevalence.
  • What else on musl compares crypt() output to a stored field. Nobody appears to have looked, and we have not either.