Some server accounts are set up so that no password can ever open them. They are meant to be reached only with an SSH key, or not at all. For ten years, on one family of Linux systems, those accounts would accept any password, as long as it was longer than 256 characters. The flaw became public on 5 November, and attackers were using it the next day.
What happened
On Linux, an account that should never log in with a password has an asterisk (*) where its password hash would normally be. An asterisk is not a valid hash, so no password can ever match it. Many key-only accounts, service accounts and the root account on Alpine are set up this way.
Two decisions made years apart broke that rule. In 2012, the musl C library, which Alpine and many small Linux systems use instead of the more common glibc, decided that when its password-hashing function fails it would return an asterisk rather than nothing. Around the same time it capped passwords at 256 bytes, so a longer one makes the hashing fail. In 2016, OpenSSH fixed an unrelated bug by hashing every submitted password even for accounts with no usable hash, to avoid giving away which usernames exist.
Put together, a password longer than 256 bytes makes the hashing fail, the failure returns an asterisk, and OpenSSH compares that asterisk with the asterisk stored for the locked account. They match, and the attacker is in. Kültekin found it by building OpenSSH every way he could think of and throwing about 17,600 unusual logins at each build. Every build agreed on every login, except musl without PAM.
OpenSSH released a fix the morning it was disclosed. The researcher's write-up followed three hours later, and exploit code was on GitHub within the hour after that. GreyNoise recorded its first successful exploitation about 40 hours after the fix. By 12 November it had confirmed 42 sessions of attacker activity on its decoy servers after a successful break-in, from ten addresses. The attackers looked around the system, went after password hashes, SSH keys and cloud credentials, and edited files, including adding their own SSH keys so they could get back in after the hole was closed.
Why it matters
Most businesses do not know which of their systems run Alpine. It is popular precisely because it is small. It shows up in cloud servers someone created from a marketplace image, in containers, and inside appliances where the operating system is invisible to the owner. If one of those has SSH open to the internet with passwords allowed, it may have been open to anyone.
The accounts affected are the ones you trusted most. The bug only touches accounts that were deliberately locked against passwords. Administrators lock accounts that way because they are sensitive, so the bypass lands exactly where it does the most damage.
The window between fix and attack is now hours. The fix, the explanation and a working exploit all appeared on the same day. This is the pattern we keep writing about: when flaws are found with AI and published quickly, attackers are ready within a day, so patching on a monthly schedule is no longer enough for anything exposed to the internet.
Some common systems are safe. Debian, Ubuntu, Fedora and other glibc-based systems are not affected, and neither are systems that check passwords through PAM. Most OpenWrt routers use a different SSH server, Dropbear, which is also not affected. An Alpine container that does not run an SSH server is not exposed either.
What to actually do
Find anything running OpenSSH on Alpine, or on embedded Linux, that is reachable from the internet. Ask whoever runs your cloud servers and hosting, and check appliances that offer SSH access. If you cannot tell what a device runs, ask the vendor whether it is affected by CVE-2026-123158.
Update OpenSSH. On Alpine, run apk upgrade openssh; fixed packages are available for every supported Alpine release. Elsewhere, the fix is OpenSSH 10.6p2 or your vendor's patched build.
Turn off password logins for SSH. If you cannot update immediately, set PasswordAuthentication no in the SSH server configuration and restart it. Servers reachable from the internet should use SSH keys only anyway, and this setting blocks the attack completely.
Check whether you were already hit. On Alpine, look for successful password logins with grep "Accepted password" /var/log/messages. A password login to an account that has an asterisk in /etc/shadow, such as the default alpine user, means the flaw was used. Also look for SSH keys in authorized_keys files that nobody recognises: attackers add their own so they can return after you patch.
If you find a break-in, treat the server as compromised. Patching closes the hole but does not remove what an attacker left behind. Rebuild the server, and change any passwords, keys and cloud credentials it held.
The summary
For ten years, on a popular family of small Linux systems, accounts locked against passwords would open for any very long one. Attackers started using it within two days of the fix. If you run anything on Alpine or embedded Linux with SSH open to the internet, update OpenSSH, turn off password logins, and check the logs and the SSH keys for signs that someone got there first.
Sources
- OpenSSH 10.6p2 release notes — OpenSSH
- CVE-2026-123158 — CVE record
- *sshole — Özgün Kültekin, Wakefield
- SSHole (CVE-2026-123158) activity — GreyNoise
- CVE-2026-123158 — Alpine Linux security tracker
- Known Exploited Vulnerabilities Catalog — CISA
