On Alpine Linux and a handful of other lightweight systems, an attacker who could reach an SSH server was able to log in to accounts that were never meant to accept a password at all. They didn’t need to guess anything. A single attempt with a password between 257 and 1,024 characters was enough, provided a few ordinary configuration conditions lined up.
OpenSSH shipped version 10.6p2 on 5 November to close the hole. Its maintainer, Damien Miller, opened the announcement bluntly: anyone running Linux with the musl C library and without PAM, “Alpine Linux is one example”, should “stop reading” and disable password logins or SSH “IMMEDIATELY”. Alpine published its own advisory the same day, warning that the attack “takes one connection, works every time, and needs no retries”.
Two reasonable decisions that collided
The bug, nicknamed SSHole and reported by Özgün Kültekin of the security firm Wakefield, comes from two components each behaving sensibly on their own.
On Linux, an account can be marked as unable to use a password by storing a single asterisk where its password hash would normally sit. Key-only users are often set up that way, and Alpine’s base image has stored root’s password field as * since roughly release 3.16.
In 2016, OpenSSH changed how it handled such accounts to fix a username-enumeration flaw, CVE-2016-6210, BleepingComputer reports. The problem had been timing: a server that skipped the hashing step for accounts without a real hash answered faster, letting attackers tell real usernames from fake ones. The fix was to hash the attempt anyway, borrowing the salt from another account on the machine.
That’s where musl comes in. Alpine explains that when its crypt() function receives a key longer than 256 bytes, it returns the string to signal an error. sshd then compares that output with the stored field, which is also . The two match, and the login succeeds. Accounts with a real password hash can’t be opened this way.
Miller wrote that the project considers “the root cause of this bug to be outside OpenSSH itself”, but that OpenSSH was best placed to deliver a fix quickly. Systems built on glibc, which covers Debian, Ubuntu, Fedora and most mainstream distributions, don’t behave this way, and neither do systems that check passwords through PAM.
Narrower than the headline, sharper than it looks
Every condition has to be true at once, according to Alpine. sshd must be built without PAM, which is how Alpine’s standard openssh-server package ships (the separate openssh-server-pam package is also exposed if UsePAM no is set). Password authentication must be on, which is OpenSSH’s default. At least one account must have * in its password field. And at least one other local account must have a normal $5$ or $6$ password hash.
That last condition is the one administrators are most likely to trigger by accident. Alpine’s official tiny-cloud images for AWS, Azure and other platforms, from 3.18.11 through 3.24.3, ship an alpine user with a * password field and passwordless doas, the Alpine equivalent of sudo. They’re safe on first boot, Alpine says, but become exploitable “as soon as any $6$ hash exists on the machine”, for example when an admin sets a console password. From there an attacker gets a shell as alpine and can become root.
Root itself is protected by OpenSSH’s default PermitRootLogin prohibit-password, unless someone has changed it. Containers are mostly out of scope: Alpine says Docker users who don’t run sshd inside the container aren’t affected, and cloud images configured by cloud-init write PasswordAuthentication no by default.
Reports have listed OpenWrt, Buildroot and Yocto alongside Alpine because they also use musl. That’s accurate as a description of the library, but exposure on those platforms still depends on running OpenSSH without PAM. OpenWrt, for instance, is built around the lightweight Dropbear) SSH server, so a typical router is far less likely to be in the firing line than a hand-built Alpine VPS. Device owners should check which SSH server they actually run rather than assume.
Alpine says every release it checked is affected, from 3.16 to 3.24 and edge, and it has published fixed packages back to 3.16, including releases that no longer get regular updates.
What to do
The fix is to update and then restart the daemon. On Alpine that means apk upgrade -U -a followed by rc-service sshd restart; Alpine stresses that upgrading the package does not replace an sshd process that’s already running. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the patched package, and Alpine’s advisory lists the exact fixed version for each branch.
Where an immediate update isn’t possible, setting PasswordAuthentication no and restarting sshd closes the hole. Alpine advises confirming that key-based login works, and keeping an existing session open, before making that change.
Administrators should also look backwards. Alpine suggests searching /var/log/messages for Accepted password for lines involving accounts that have no password, such as alpine, root or key-only users, and reviewing recent doas use, new accounts and authorised keys. If a login can’t be ruled out, the advisory says to treat the machine as compromised.
The one-day patch and the AI factor
The speed of the response is part of the story. Miller wrote that the project learned of the problem the day before release and skipped a long embargo because “we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours”. Kültekin told BleepingComputer he found the flaw using AI agents that ran about 17,600 authentication tests across different configurations.
It’s a notable shift in disclosure practice, and it echoes the pressure on patching we examined in our piece on OpenAI’s GPT-6 Cyber. The trade-off is that downstream maintainers get almost no warning; Miller thanked Alpine’s developers for producing packages “at very short notice”.
None of the sources we consulted had confirmed exploitation as of reporting. Alpine’s advisory doesn’t report any, and Detectify co-founder Fredrik Almroth told SecurityWeek: “We haven’t seen any reports of exploitation yet, but the details are public, and the attack is simple, so I expect scanning to start within hours.” SecurityWeek reports the bug is tracked as CVE-2026-123158 with a CVSS score of 8.1; Alpine said no CVE had been assigned when it published, so treat that identifier as SecurityWeek’s reporting until it appears in official CVE records.
For most people reading this on a phone or a Windows laptop, nothing needs doing. For anyone running an Alpine server with SSH open to the internet, the safe assumption is that someone will try this soon, and the fix takes a minute.
Correction, 8 November 2026: An earlier version of this article said some security outlets had reported attacks beginning within hours of disclosure. The sources we consulted did not confirm exploitation as of reporting; researchers quoted by SecurityWeek said they expected scanning to begin. The earlier version also attributed the CVE identifier to BleepingComputer; it was reported by SecurityWeek.
