OpenSSH Password Bypass on Alpine Linux and How to Close It

On November 5, 2026, the OpenSSH project released OpenSSH 10.6p2 with a workaround for a password bypass in sshd. The same day the flaw was published as CVE-2026-123158 with a CVSS score of 8.1. It only affects Linux systems where sshd runs on the musl C library without PAM. In practice that means Alpine Linux, Docker images built on Alpine when they run an SSH server, and embedded builds such as OpenWrt, Buildroot and Yocto when they ship OpenSSH. Debian, Ubuntu, Fedora and Red Hat Enterprise Linux use glibc and are not affected.

The fix is already in Alpine's edge branch as openssh 10.6_p2-r0. The stable branches, 3.20 to 3.24, had no updated package when we checked on the evening of November 5. Until they do, one setting closes the hole on any affected server, and it is a setting most hardened servers should have anyway. Turn off password logins and keep SSH keys.

Hosting providers have started emailing customers about it, including customers who run nothing but Ubuntu, so plenty of teams are asking whether they need to do anything. This article answers that, shows how to check a server in under a minute, and gives the change we tested on Alpine 3.24.

Where the Fix Stands on November 5

Working demonstrations of the bypass are public, and CISA's enrichment of the CVE record notes a proof of concept. The flaw is not in CISA's catalogue of exploited vulnerabilities. The CVSS vector rates the attack complexity as high, because the target needs several conditions at once, which we list below. Many Alpine servers will not meet all of them, but the combination is common enough that waiting for the package is the wrong call.

What Goes Wrong, in Plain Terms

When sshd runs without PAM, it checks a password itself. It hashes what the user typed with the C library's crypt() function and compares the result with the hash stored in /etc/shadow. If the two strings match, the user is in.

Accounts that should never log in with a password carry a placeholder instead of a hash, and on Alpine that placeholder is often a single asterisk. Since 2016, sshd hashes the typed password even for such accounts, borrowing the salt of another account that has a real hash. That behaviour came from the fix for CVE-2016-6210, and its purpose was to stop response times from revealing which usernames exist.

musl's crypt() reports failure differently from glibc. Instead of returning nothing, it returns an asterisk, and an oversized password is one of the ways to make it fail. So for an account whose stored value was an asterisk, sshd compared an asterisk with an asterisk and let the user in. glibc does not answer a failure that way, which is why glibc systems were never exposed.

The OpenSSH developers consider the root cause to sit outside OpenSSH, but sshd was the quickest place to stop it. Damien Miller's change refuses to treat any stored value shorter than four characters as a password hash, so a placeholder can no longer match anything. The bug was reported by Özgün Kültekin of Wakefield, whose team ran about 17,600 authentication tests with AI agents across OpenSSH configurations to find it. OpenSSH heard about it the day before the release and chose not to wait, with Miller noting that AI agents now rediscover bugs within hours, which makes long embargoes risky.

Who Is Affected and Who Is Not

A server is exposed only when every one of these is true.

• sshd is OpenSSH linked against musl. Dropbear is a different program and is not affected.
• Passwords are not checked through PAM. Alpine's standard openssh-server package is built without PAM, so this is the default there.
• Password logins are allowed. On Alpine 3.24 the default is PasswordAuthentication yes.
• An account that can log in over SSH has a single asterisk as its password field.
• Another account on the same system has a real password hash.

We checked a fresh Alpine 3.24 container to see which accounts carry the asterisk. Root does, since Alpine changed root from an exclamation mark to an asterisk in 3.16 so that root could log in with keys. The default PermitRootLogin prohibit-password still refuses password logins for root, so root is only reachable where someone has set PermitRootLogin yes.

The more common exposure is ordinary key-only users. adduser -D creates an account with an exclamation mark in the password field, and sshd without PAM treats that as a locked account and refuses it even with a valid key. A widespread workaround is to replace the exclamation mark with an asterisk, which makes key logins work and also makes the account reachable by this bug. Accounts that still have the exclamation mark are not affected, because musl never returns that string.

The researcher also points to Alpine's official AWS and Azure images, which ship a default alpine user with passwordless doas. On those machines a bypass on that one account amounts to root.

Check Your Servers

These commands answer the question on a single machine. Run them as root.

cat /etc/os-release
ldd /usr/sbin/sshd | grep -i musl
apk list -I | grep openssh-server
sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '
awk -F: '$2=="*" {print $1}' /etc/shadow

If /etc/os-release says Ubuntu or Debian, you can stop there, since ldd will show libc.so.6, which is glibc. On Alpine, ldd prints ld-musl, and apk list shows the installed version. Anything older than 10.6_p2 needs the change in the next section, unless your branch has shipped a backport that lists CVE-2026-123158 in its security fixes.

The sshd -T line prints the settings sshd is really using, after every include and default. If it shows passwordauthentication yes, password logins are on. The last command lists the accounts whose password field is exactly an asterisk. If that list is empty, or password logins are already off, the server does not meet the conditions above.

Alpine also ships openssh-server-pam, which installs a PAM build of the daemon as /usr/sbin/sshd.pam. That build is only out of scope when it is the daemon actually running and UsePAM yes is set, since on Alpine 3.24 it reports usepam no until you change it. The standard package prints no usepam line at all, because it has no PAM support to switch on.

Close It Today

Before changing anything, make sure you can log in with a key, and keep that session open while you work. Then add a drop-in file that turns password logins off.

mkdir -p /etc/ssh/sshd_config.d
cat > /etc/ssh/sshd_config.d/00-no-passwords.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
EOF
sshd -t && rc-service sshd restart
sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '

We ran this on Alpine 3.24 with openssh 10.3_p1-r2. sshd -t accepted the file, and sshd -T changed from passwordauthentication yes to passwordauthentication no. It works because Alpine's sshd_config includes /etc/ssh/sshd_config.d/*.conf near the top, and sshd keeps the first value it reads for each setting, so the 00- file wins over anything later in the main file. Restarting sshd leaves existing sessions connected, but open a second session and log in with your key before you close the first one.

Match blocks are the one thing this file does not override. If your configuration contains something like Match Address 10.0.0.0/8 followed by PasswordAuthentication yes, passwords are still allowed from those addresses. Search for them with grep -n Match /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf and fix them too.

If a server genuinely needs password logins until the package arrives, switching to openssh-server-pam with UsePAM yes takes it out of scope. That is a bigger change than a drop-in file, so test it on one machine first.

Containers, Cloud Images and Embedded Devices

Most Alpine-based Docker images do not run sshd at all, and an image without an SSH server is not affected. The ones worth a look are SSH jump hosts, SFTP and Git servers and development containers built on Alpine. docker ps --format '{{.Names}} {{.Image}} {{.Ports}}' shows what each container publishes, and any container exposing port 22 deserves the checks above, run inside it with docker exec. The durable fix is in the image itself. Add the same drop-in file to the Dockerfile and rebuild, so a restarted container does not come back with passwords on.

The same goes for Kubernetes. A pod running sshd from an Alpine base image is exposed on the same terms, whatever the node runs, and the fix again belongs in the image.

Alpine machines started from the official AWS or Azure images should get a look at the alpine account in particular. grep '^alpine:' /etc/shadow shows whether its password field is an asterisk, and the drop-in file closes it either way.

On routers and appliances the answer depends on how the firmware was built. OpenWrt uses Dropbear by default, so only devices where someone installed OpenSSH need checking. Buildroot and Yocto images can ship either server, with or without PAM, so a device built on them is a question for its vendor or its build configuration.

Signs of Misuse

On Alpine, sshd logs through syslog, and the default destination is /var/log/messages. A key-only account should never show a password login, so this search is a quick first look.

grep "Accepted password" /var/log/messages

Compare the usernames against the asterisk list from the check above. An accepted password for an account whose password field is an asterisk should not happen on a healthy server. Treat it as a compromise, look at authorized_keys files, cron jobs and running processes, and plan to rebuild the machine rather than clean it. Bear in mind that logs on a compromised machine can be edited, so logs shipped to another system are the more reliable record.

When the Fixed Package Arrives

Once your Alpine branch publishes a fixed openssh, the upgrade is one command.

apk update && apk upgrade openssh
rc-service sshd restart
apk list -I | grep openssh-server

Edge already has 10.6_p2-r0. A stable branch may instead backport the fix into its current version with a higher release number, so check Alpine's security database for CVE-2026-123158 rather than looking only for 10.6. After the upgrade, keep the drop-in file. Key-only logins were the safer setting before this bug, and the next authentication flaw will find fewer doors open.

What This Means for Your Team

If your servers run Ubuntu, Debian or RHEL, the email from your hosting provider is not a reason to act on this flaw. Those systems use glibc, and their OpenSSH packages check passwords through PAM. The Linux kernel flaw we covered three days ago does affect them, and Ubuntu and RHEL kernels were still on the way, so if you want to spend the time on something, CVE-2026-98432 and its firewall stopgap is the better use of it.

If you run Alpine, the job today is one file and a restart per server, plus a look at any container that runs sshd. The package update can follow when your branch ships it. Teams that would rather hand this over can ask us to check their fleet and turn off password logins as part of our servers management work, with the package update scheduled once it lands.

Sources

• CVE-2026-123158 record
• OpenSSH 10.6p2 release notes
• OpenSSH commit 4353fdc, avoid password authn bypass
• undeadly.org on the OpenSSH 10.6p2 release
• The researcher's write-up at sshhole.com
• BleepingComputer on the flaw
• heise on the release and Alpine
• Alpine aports, openssh package
• CISA Known Exploited Vulnerabilities catalog