A 257-byte password can open some Alpine servers. Check yours in two minutes.

If you run Alpine anywhere with SSH open, a tiny VPS, a cloud image, a box under the desk, read this before you close the laptop today.

On 5 November, OpenSSH shipped version 10.6p2 with a fix it calls critical for Linux systems that use the musl C library and run without PAM. That is exactly how Alpine’s default openssh-server package is built. The bug is tracked as CVE-2026-123158, and some write-ups call it “sshole”. The release notes credit Özgün Kültekin of Wakefield for reporting it.

How a long password gets in

You don’t need to read C to follow this. Four small facts line up:

• Accounts you meant to lock, like root on recent Alpine or a user that only logs in with keys, often have a * in /etc/shadow instead of a password hash.
• With PAM turned off, sshd checks passwords itself by calling crypt().
• musl’s crypt() refuses SHA-256 and SHA-512 passwords longer than 256 bytes. When it refuses, it returns the string *.
• sshd compares that * with the stored *. They match, so the login succeeds.

So the “wrong” password is simply a very long one. OpenSSH says the root cause sits outside sshd, and musl’s maintainer says it is the caller’s mistake. You don’t have to pick a side. Version 10.6p2 blocks it inside sshd either way.

Are you affected?

All four of these have to be true:

1. musl libc. Alpine, and many embedded or self-built systems. Debian, Ubuntu, RHEL and other glibc distributions are not affected.
2. OpenSSH without PAM. Alpine’s default openssh-server package. The openssh-server-pam setup with UsePAM yes is not affected.
3. Password login switched on. PasswordAuthentication yes is the default.
4. At least one account with * in the password field. On Alpine that includes root on recent releases, and the alpine user on official cloud images, which OX Security says can become root through passwordless doas.

Dropbear, the small SSH server many routers use, is a different program and is not affected.

The two main write-ups disagree on details. OX Security lists root as reachable. TuxCare found that the default PermitRootLogin setting blocked root in its lab. They also disagree on whether one attempt is enough or two. Don’t plan around the hopeful version. If the four conditions match your server, treat it as open.

The two-minute check

Run these on the Alpine machine as root:

apk info -v openssh-server                          # installed version
ldd /usr/sbin/sshd | grep musl                      # prints a line = musl
sshd -T | grep -iE 'passwordauthentication|usepam'  # yes / no?
awk -F: '$2=="*"{print $1}' /etc/shadow             # accounts with *

Compare the version with the fixed packages on the Alpine tracker: 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21, 9.7_p1-r6 on 3.20 and 9.6_p1-r3 on 3.19. OX Security and TuxCare also list 9.3_p2-r4 for 3.18.

Fix it

apk upgrade -U
rc-service sshd restart

The restart matters. The old sshd keeps running until you restart it.

If you can’t upgrade today, turn password login off. Put PasswordAuthentication no in /etc/ssh/sshd_config, restart sshd, and confirm with sshd -T. On Alpine 3.19 and newer, a file in /etc/ssh/sshd_config.d/ also works. TuxCare says 3.18 and older ignore that folder, so edit the main file there.

Using Alpine in Docker? Rebuild your images from a patched base. An image you built last week still carries the old package, and it stays old until you rebuild.

Was anyone already in?

None of the sources I read report attacks in the wild as of today. That can change fast once a bug is public, so look anyway:

grep 'Accepted password for' /var/log/messages

On a server where everyone logs in with keys, that should print nothing. If you see a line you can’t explain, treat the machine as compromised: take it offline, rotate its keys, and rebuild it.

The habit worth keeping

“Locked” only means locked if every layer agrees on what that means. Here, three pieces of software each made a reasonable choice, and together they opened a door.

If you only ever log in with keys, write that down in the config. PasswordAuthentication no is one line, and it closes this whole family of bugs, including the next one.