OpenSSH Authentication Bypass: How a Long Password Opens Alpine Servers

An OpenSSH authentication bypass disclosed on 5 November lets a stranger log in over the internet without knowing a password. It does not hit every server. It hits Linux machines built on the musl C library with PAM switched off, and that description fits Alpine Linux out of the box. The flaw has a nickname, SSHole, and a CVE number, CVE-2026-123158. Attackers did not wait long to try it.

What the OpenSSH authentication bypass actually does

Many Linux accounts have no usable password. Instead of a hash, the password field holds a single asterisk. Think of root on a key-only server, or a service user created by a cloud image.

When sshd runs without PAM, it hashes the password a visitor types and compares the result with that stored field. According to the Alpine Linux advisory, musl’s hashing function returns an asterisk as its error value when the input is longer than 256 bytes. So a very long password produces an asterisk, the account’s field is also an asterisk, and the two match. The login succeeds.

The attacker needs a password between 257 and 1,024 bytes and the name of an account with no password. Root is the obvious guess. Alpine adds one condition: at least one other account on the box must have a real $5$ or $6$ hash.

Who is exposed

Alpine says every release from 3.16 through 3.24, plus edge, is affected when it runs the standard openssh-server package, or the PAM package with UsePAM no. Password authentication must also be on, which is the OpenSSH default. Horizon3 also lists OpenWrt and embedded devices that run OpenSSH on musl.

Servers that use glibc are not affected. Neither are systems that check passwords through PAM, nor hosts with PasswordAuthentication no. Alpine also notes that locked accounts, marked with an exclamation mark, are safe.

The CVSS score is 8.1, high rather than critical, because the attacker must know a suitable account name and the setup has to line up. That is a poor comfort. Alpine is popular in containers and small appliances, and plenty of those expose SSH.

How fast attackers moved

The OpenSSH 10.6p2 release notes, dated 5 November, call this a critical security workaround. The notes say the root cause sits outside sshd, in the library, but sshd can avoid it. Previdian’s telemetry page says the CVE went public at 15:46 UTC and a working proof of concept followed at 17:30 UTC the same day.

Scanning for the OpenSSH authentication bypass began almost at once. Previdian’s sensors logged 14 attempts from nine IP addresses in eight countries on 6 November. It rates exploitation as confirmed but is careful to say that attempts do not prove any target was vulnerable.

The Hacker News reported that Previdian saw a first attempt under nine hours after publication and confirmed root access on an Alpine honeypot. The attacker ran only id, uname and hostname, the usual first look around a new foothold.

What to do this week

First, find out whether you run Alpine, OpenWrt or any appliance built on musl with SSH exposed. Container base images count, even if nobody remembers choosing them.

Then patch. Upgrade to OpenSSH 10.6p2 or your distribution’s backport. On Alpine that means apk upgrade -U -a. Restart the daemon afterwards, because Alpine warns that upgrading the package does not restart the process that is already running.

If you cannot patch today, set PasswordAuthentication no and restart sshd. Check that key-based login works first, and keep one session open while you test.

Finally, look back. Alpine suggests searching /var/log/messages for “Accepted password for” lines on accounts that should never log in with a password, such as root or key-only users. Review recent users, new files and authorized keys too. If you cannot rule out a login, treat the machine as compromised.

Why small teams get caught

Few people choose musl on purpose, which is why the OpenSSH authentication bypass will surprise them. It arrives inside a base image, a router firmware or a vendor appliance, and nobody writes it down. That is why asset lists matter more than the patch itself. If you cannot say which of your systems run Alpine, you cannot say whether you are exposed.

The account condition catches people out too. Cloud images often create a default user with no password and rely on keys. Those accounts look safe because nobody ever set a password for them. This bug turns that lack of a password into the way in.

Finally, the advice to watch the logs only helps if you keep them. A small server that rotates logs every few days may have lost the evidence already. Ship authentication logs somewhere central, so you can answer “did anyone log in?” after the event.

What this says about SSH exposure

This OpenSSH authentication bypass is a reminder that a safe default today can hide an old assumption. The Hacker News traces the flaw to a 2016 change made to stop username enumeration, which is a long time for it to sit unseen. Password logins on internet-facing SSH are a standing risk. Keys, a VPN or a bastion host remove most of it.

A penetration test finds this kind of gap quickly, because testers check which services answer from outside and how they authenticate. If you want a second opinion on your exposed services, our guide to modern penetration testing explains what a good scope looks like. We also covered how attackers hijacked Tor relays to harvest SSH passwords, another case where password logins were the weak point.