OpenSSH password-auth bypass on Alpine (musl): are you affected, and the 10.6p2 fix

On 5 November 2026, OpenSSH released 10.6p2 with what its own notes call a "critical security workaround" for a password-authentication bypass. The scope is narrow but sharp: it affects Linux systems that use the musl C library — most commonly Alpine — when sshd is built and run without PAM, which is Alpine's default. On an exposed box, a login that should be rejected can be accepted.

If you run on glibc — Debian, Ubuntu, Fedora, and the usual VPS images — you are not affected by this, and neither is anything that goes through PAM. This guide shows exactly who is exposed, how to check in two minutes, and the one-line fix (plus a stopgap that works right now).

Want your servers checked and patched for you? Security patching →

What was found

The issue was reported by Özgün Kültekin of Wakefield, and OpenSSH credits the report in the 10.6p2 notes. In OpenSSH's own words, the fix lets sshd "avoid password authentication bypass that is exploitable through sshd that affects some Linux systems when built and run with PAM support disabled", and it adds that it considers the root cause to be outside sshd but avoidable there.

In plain terms: on an affected box, a password login that should fail — against an account that has no usable password — can be made to succeed. The practical worry is accounts that are "locked" or key-only but still exist, and systems where a successful login lands somewhere with a quick path to root.

Are you affected?

Four things have to be true at once. If any one is false, this particular bypass does not apply to you.

• You are on musl libc. Alpine is the common case; the researcher also lists OpenWrt, Buildroot and Yocto. Debian, Ubuntu, Fedora and other glibc distros are out.
• sshd is built/run without PAM. Alpine's default openssh-server is built without PAM (PAM support is a separate package), or you have set UsePAM no.
• Password authentication is enabled (PasswordAuthentication yes, the default).
• OpenSSH is older than 10.6p2. Any build from before 5 November 2026 that you have not updated.

Why musl, and why not Debian/Ubuntu

The reason it is a musl-only problem comes down to a C-library detail, not to sshd. According to the researcher's write-up, musl's crypt() returns the short string "*" on failure instead of a null result, and its SHA-crypt refuses passwords longer than 256 bytes. Because a locked account's password field is also "*", an over-long password can make a failed hash and a stored "locked" marker look the same to the comparison that follows. OpenSSH agrees the root cause is outside sshd, which is why glibc builds — where crypt() behaves differently — and PAM-based logins (PAM never hashes a "*" field) are not affected.

That is also why you can trust the simple test below: it is the combination of musl, no PAM, and password auth that opens the path, and breaking any link closes it.

Check in two minutes

Print your distro, your OpenSSH version, and the two settings that decide exposure. If you are on musl with usepam no, passwordauthentication yes, and OpenSSH below 10.6p2, patch.

# Which distro? Alpine and other musl systems are the ones at risk
grep -E '^(ID|VERSION_ID)=' /etc/os-release

# OpenSSH version — 10.6p2 or later is fixed
ssh -V

# The two settings that decide exposure: is PAM off, and password login on?
sshd -T 2>/dev/null | grep -iE '^(usepam|passwordauthentication) '

ID=alpine
VERSION_ID=3.20.3
OpenSSH_9.9p1, OpenSSL 3.3.2        # below 10.6p2 -> unpatched binary
usepam no                          # PAM off -> the bypass path is open
passwordauthentication yes         # password login on -> it is reachable

There is also a standalone detector from the researcher at github.com/oz9un/sshole, if you want a second opinion.

The fix

The real fix is the OpenSSH update. The stopgap — turning off password auth — removes the exposure immediately and is good practice on any internet-facing server anyway.

1. 1
   Update OpenSSH and restart. On Alpine, apk update && apk upgrade openssh, then rc-service sshd restart. Confirm with ssh -V that you are at 10.6p2 or later.
2. 2
   If the package isn't in your mirror yet, use the stopgap: disable password authentication so the bypass has nothing to act on, then update as soon as the package lands.
3. 3
   Rebuild your Alpine images. A running container keeps its old OpenSSH until the image is rebuilt from a patched base and redeployed — pulling alone changes nothing already running.
4. 4
   Audit who can log in with a password. Prefer keys everywhere; on an internet-facing host there is rarely a reason to leave password auth on at all.

apk update
apk upgrade openssh
ssh -V                 # confirm 10.6p2 or later
rc-service sshd restart

# Immediate stopgap: turn off password auth (use keys), then restart
printf 'PasswordAuthentication no\n' > /etc/ssh/sshd_config.d/00-no-passwords.conf
rc-service sshd restart

Common questions

Want your fleet checked and patched?

I audit which of your servers are exposed — distro, OpenSSH version, PAM and password settings — update OpenSSH across hosts and Alpine images, move you to keys-only cleanly, and verify it on each live box. See security patching or bug fixing and debugging. It pairs naturally with the APT patching guide for the rest of your server surface.

Sources

• OpenSSH release notes — 10.6p2 (5 Nov 2026), the authoritative fix and scope
• sshhole.com — the researcher's disclosure and mechanism write-up (Özgün Kültekin)
• oz9un/sshole — standalone detector on GitHub