OpenSSH Alpine password bypass: four conditions to check

The openssh alpine password bypass disclosed on 5 November 2026 lets a password of 257 to 1024 bytes log into accounts that have no password at all, but only when four conditions hold at once. By the end of this post you'll know which of your Alpine hosts and sshd images meet them, what to change today, and when to treat a box as compromised.

The most expensive mistake is the obvious fix done halfway. Alpine's advisory says plainly that upgrading the package does not restart a running sshd. An apk upgrade that isn't followed by a restart leaves the old daemon listening, so the host is still exploitable.

Fact	Detail
Disclosed	5 November 2026, in the OpenSSH 10.6p2 release, Alpine's advisory and oss-security
Identifier	CVE-2026-123158, CVSS 3.1 score 8.1 (High) from MITRE; NVD status "Received" as of 6 November 2026
Who is exposed	musl builds of sshd without PAM, mainly Alpine's openssh-server package
Upstream fix	OpenSSH 10.6p2; Alpine packages for every branch from 3.16 to edge
Stopgap	PasswordAuthentication no, then restart sshd

How the openssh alpine password bypass works

When sshd is built without PAM, it checks a password by running the attempt through crypt() and comparing the result with the stored password field. According to the Alpine advisory, musl's crypt() returns the string * as an error indicator when the key is longer than 256 bytes. A * is also exactly what the stored field contains for an account with no password, so the comparison matches and the login succeeds.

There's one more step, and it explains the fourth condition. For an account whose stored field is too short to contain a salt, sshd borrows the salt of another account. That's why Alpine says one local user with a real password hash "makes every account without one reachable". Accounts that do have a valid hash are not bypassed, a point BleepingComputer makes explicitly.

The maintainers don't agree on whose bug this is. The OpenSSH 10.6p2 notes say the team considers the root cause to be outside sshd, but exploitable through it and avoidable there. musl maintainer Rich Felker wrote that it is not a bug in musl but an erroneous use by the caller, while adding that the mechanism "very likely will be changed in the upcoming release cycle". For your fleet the disagreement changes nothing today: the fix you can ship is in OpenSSH and Alpine's packages.

The four conditions, and the one headlines dropped

Alpine's advisory lists what must all be true for a machine to be exploitable:

1. You run Alpine's openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no.
2. PasswordAuthentication is yes, which is the OpenSSH default.
3. An account has * as its password field: a key-only user created without a password, users from a directory service through musl-nscd, or the alpine user in tiny-cloud images.
4. At least one local account has a $5$ or $6$ (SHA-256 or SHA-512) password hash.

Some headlines led with root, such as daily.dev's "Gives Attackers Root on Alpine Linux". The primary source is narrower. Alpine says root has shipped as root:* since about 3.16, but OpenSSH's default PermitRootLogin prohibit-password protects it, so root is directly reachable only if you set PermitRootLogin yes. The real route to root is indirect: any other account that can log in and then escalate, for example through doas.

Which Alpine images are vulnerable

Alpine found the bug in every release it checked: 3.21 through 3.24 and edge, plus 3.16 to 3.20, which no longer get regular updates. 3.21 reached end of support on 1 November 2026, but Alpine published fixed packages all the way back to 3.16. Cycode reports that images on Alpine releases before 3.16 were exploitable in its lab and get no fixed package.

Cloud images need the closest look. The official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. Alpine says they are safe on first boot and become exploitable as soon as any $6$ hash exists, for example when an admin sets a console password or user-data adds a user with hashed_passwd. Images configured through cloud-init are not affected, because cloud-init writes PasswordAuthentication no.

Is my Alpine container vulnerable to sshole?

An Alpine container that doesn't run sshd isn't affected, so most of your base images are out of scope. The ones to find are images that run an SSH server. Cycode tested public Docker Hub SSH images and found that "a small number were exposed under their documented setup". It named Gitea, Gogs, the Jenkins SSH agent and linuxserver's openssh-server as turning password logins off, the last unless PASSWORD_ACCESS=true is set. Its suggested search is for Dockerfiles that set passwords with chpasswd while leaving password logins on.

Does sshole affect Ubuntu or Debian?

No. OpenSSH's Damien Miller wrote that the vulnerability does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication. BleepingComputer names Debian, Ubuntu and Fedora as glibc systems that are not vulnerable.

Other musl systems are a different story. BleepingComputer lists OpenWrt, Buildroot and Yocto alongside Alpine. Felker's advisory adds that Dropbear and other non-OpenSSH software using password logins is not affected, so on embedded devices the first question is which SSH server the image actually ships.

Is upgrading enough without restarting sshd?

No. Run apk upgrade -U -a, then rc-service sshd restart. Alpine's point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package. Check the installed version against this table from the advisory:

Branch	Fixed openssh package
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20 to 3.16	9.7_p1-r6, 9.6_p1-r3, 9.3_p2-r4, 9.1_p1-r7, 9.0_p1-r6

For containers, a running container doesn't pick up a new package. Cycode's advice is to rebuild and redeploy images that carry older openssh packages. That's the same lesson as the Tailscale SSH vulnerability: the patch is only half the job, and what's actually running is the other half.

Disable password authentication in sshd on Alpine

If you can't upgrade today, Alpine's workaround is a drop-in file, /etc/ssh/sshd_config.d/00-no-passwords.conf, containing PasswordAuthentication no. Alpine's default config reads that directory only from 3.19 onward, so older releases also need every PasswordAuthentication yes line in the main config changed, including those inside Match blocks. Validate with sshd -t, restart, and confirm that sshd -T | grep -i passwordauthentication prints passwordauthentication no. Keep your current session open until you've tested a new key login.

Is the openssh alpine password bypass exploited yet?

Neither Alpine's advisory nor OpenSSH reports exploitation in the wild as of 6 November 2026. CISA's enrichment on the CVE record marks exploitation as "poc" and automatable as "no", and the record links to public reproduction labs. Don't read that as time to spare. Miller wrote that OpenSSH learned of the problem the day before release and moved fast because it had seen bugs rediscovered by AI agents, "sometimes within hours".

The strongest case for waiting is real: attack complexity is rated High, and four conditions have to line up. But the tiny-cloud case shows how quietly that happens. A single console password set during an incident turns a safe instance into an exploitable one, with nothing in the sshd config changing.

How do I check for compromise?

Alpine says to search /var/log/messages for sshd lines reading Accepted password for on an account that has no password, such as alpine, root or a key-only user. Then review doas use and recently created users, files and authorized keys on exposed machines. If you can't rule out a login, Alpine's instruction is to treat the machine as compromised. A container whose logs were never shipped off the box fails that test by default, which is a good argument for central auth logging as part of infrastructure management and monitoring.

Triage today, in this order

Start with whatever is reachable from the internet. On each Alpine bastion, run sshd -T | grep -i -E 'passwordauthentication|usepam' as root, the check Cycode suggests. If it shows password authentication off or UsePAM yes, record it and move on. If not, upgrade, restart sshd, then read the logs. For images, list the ones that install openssh-server, rebuild them on a fixed package, and redeploy. Glibc hosts and containers without sshd go to the bottom of the list.

If your bastions and sshd images are spread across accounts and registries nobody has inventoried recently, our DevOps and cloud engineering team can run that inventory with you, move admin access to keys, and wire the restart into the patch pipeline so the next advisory takes one step instead of two.