OpenSSH SSHole Flaw Lets Attackers Log In to Passwordless Alpine Linux Accounts

Attackers began trying to exploit a newly disclosed OpenSSH authentication bypass within hours of its release, and at least one honeypot running Alpine Linux was taken over with root access. The flaw, tracked as CVE-2026-123158 and nicknamed SSHole (styled “*sshole” by the researcher who found it), lets anyone who can reach an exposed SSH server log in to accounts that have no password set by sending a very long password.

OpenSSH shipped the fix in OpenSSH 10.6p2 on November 5, 2026, calling it “a critical security workaround” for Linux systems that use the musl C library with PAM disabled. Alpine Linux, which builds its default openssh-server package exactly that way, published fixed packages for every branch from 3.16 to edge the same day.

What OpenSSH and Alpine confirmed

In an urgent release notice to the openssh-unix-dev mailing list, OpenSSH developer Damien Miller told anyone running a Linux system with musl libc and no PAM to “stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”

Miller said the project learned of the problem the day before the release and moved fast on purpose: “we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers.” OpenSSH says it considers the root cause to be outside sshd, but that sshd is where it can be stopped.

Alpine’s security advisory describes the impact plainly: “An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.”

The bug was reported by Özgün Kültekin of Wakefield. The CVE record, published November 5, carries a CVSS 3.1 score of 8.1 (High) from MITRE, which assigned the identifier.

How the bypass works

When sshd is built without PAM, it checks a password by hashing the attempt with the C library’s crypt() function and comparing the result with the account’s stored password field. Accounts that should never accept a password, such as key-only users, store a single * in that field. No real hash can ever match it.

Two old design choices collide here:

• sshd borrows another account’s salt. Since a 2016 fix for a username enumeration bug (CVE-2016-6210), sshd hashes the attempt with a salt taken from another account when the target account has no usable hash, so failed logins take the same time.
• musl’s crypt() returns “*” on failure. musl caps SHA-crypt keys at 256 bytes. When a password is longer than that, crypt() fails and returns the string * as its error value.

Put together, a password of 257 to 1,024 bytes makes crypt() return *, which matches the * stored for the passwordless account, and sshd lets the attacker in. The fix in OpenSSH 10.6p2 makes sshd skip the comparison when the stored field is too short to be a real hash. The researcher says the behavior goes back years, and that the attack worked on an OpenSSH 7.5p1 build on musl 1.1.16 from 2017.

Who is affected

According to Alpine, a system is exposed only when all of these are true:

• It runs Alpine’s standard openssh-server package (built without PAM), or openssh-server-pam with UsePAM no
• PasswordAuthentication is set to yes, which is the OpenSSH default
• At least one account has * as its password field, such as a key-only user, a directory user coming through musl-nscd, or root, which has shipped as root:* since about Alpine 3.16
• At least one other local account has a real $5$ or $6$ password hash

Alpine says every release it checked is affected, from 3.21 through 3.24 and edge, plus the older 3.16 to 3.20 branches. OpenSSH’s default PermitRootLogin prohibit-password keeps root itself out of reach unless an admin changed it, but that does not help if another reachable account can become root.

That is the case for Alpine’s official tiny-cloud images. Alpine says the cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. They are safe on first boot, but become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password. An attacker then gets a shell as alpine and can use doas to become root.

Systems that are not affected include Linux distributions built on glibc (Debian, Ubuntu, Fedora and similar), anything that checks passwords through PAM, servers with PasswordAuthentication no, accounts locked with !, and containers that do not run sshd. The researcher’s checker repository also lists other musl-based systems worth checking, including OpenWrt, Buildroot and Yocto builds.

Exploitation began within hours

Exploitation-tracking firm Previdian says its sensors recorded the first attempt at 00:05 UTC on November 6, a little over 8 hours after the CVE was published at 15:46 UTC on November 5. Its CVE-2026-123158 page lists 19 exploitation attempts from 12 attacker IP addresses in 8 countries across 4 sensors as of November 8.

Previdian founder and CEO Ryan Dewhurst said the company confirmed successful root access on a Previdian honeypot running real Alpine Linux and OpenSSH. He said the attacker used oversized passwords to get past authentication and then ran reconnaissance commands such as id, uname and hostname. Previdian’s public page notes that its sensor counts are attempts and do not by themselves show that a target was vulnerable.

Public proof-of-concept code and scanners appeared on GitHub on November 5 and 6, which lowers the bar for anyone scanning the internet for exposed Alpine servers. No real-world victim organization had been publicly identified at the time of publication, and CVE-2026-123158 was not in CISA’s Known Exploited Vulnerabilities catalog when BreachNews checked.

Another fast-moving Linux bug in an AI-driven year

Miller’s warning about AI rediscovery fits a pattern BreachNews has been tracking. OpenAI recently described a pipeline that produced 948 Linux root exploits for about $1.2 million, and other recent Linux flaws such as the Debian APT root code execution bug and the Linux kernel TCP remote root flaw have moved quickly from disclosure to public tooling. Alpine itself was hit last month, when it rebuilt its GitLab server after attacks on CVE-2026-97229.

How to fix it

On Alpine, update and then restart sshd. Upgrading the package alone leaves the old daemon running:

• apk upgrade -U -a
• rc-service sshd restart

Alpine lists these fixed openssh package versions:

• 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 and 9.0_p1-r6

Alpine 3.21 reached end of support on November 1, 2026, but Alpine still published fixes back to 3.16. Admins on those older branches should patch now and plan an upgrade.

If you cannot update right away, turn off password logins. Confirm that SSH key login works first, and keep your current session open while you test a new one:

• Set PasswordAuthentication no in /etc/ssh/sshd_config (or in a drop-in file under /etc/ssh/sshd_config.d/ on Alpine 3.19 and later)
• Run sshd -t && rc-service sshd restart
• Check the result with sshd -T | grep -i passwordauthentication, which should print passwordauthentication no

Builds of OpenSSH on other musl-based systems should move to 10.6p2 or apply the upstream patch.

How to check if you were hit

Alpine advises admins to search /var/log/messages for sshd lines reading Accepted password for an account that has no password, such as alpine, root or any key-only user. Review doas use, recently created users, new files and changes to authorized_keys on exposed machines. Alpine’s guidance is direct: if you cannot rule out a login, treat the machine as compromised.

BreachNews will update this article if CISA adds the flaw to its KEV catalog or if organizations confirm compromises tied to SSHole.