What did OpenSSH patch on 5 November 2026?
OpenSSH released portable version 10.6p2 on 5 November 2026 with a workaround for a critical password-authentication bypass. The flaw affects Linux systems that use the musl C library and run the SSH daemon without PAM support. Alpine Linux is the best-known example, because its openssh-server package is built without PAM and password logins are on by default.
The bug is tracked as CVE-2026-123158. The CVE record scores it 8.1 out of 10 and describes a misinterpretation of whether a string is intended to be a password hash. An attacker who can reach the SSH port needs only an account name and a password of 257 to 1,024 bytes. No prior access, user interaction or password guess is required.
The researcher who found it publishes the bug as “*sshole”, a name that SecurityWeek renders as “SSHole”. The pun points at the missing piece. A star, not a password, sits in the password field of every affected account, and the bug turns that star into a way in.
Alpine published fixed packages the same day. Its advisory is blunt about the exposure. “An attacker who can reach your SSH port can log in without knowing any password,” it says. “It takes one connection, works every time, and needs no retries.”
That combination makes the flaw more serious than its narrow preconditions suggest. Passwordless accounts are routine on servers that rely on SSH keys for access. Alpine is also a lightweight distribution often used in container images, so an affected package can sit far from the machine an administrator thinks about.
OpenSSH is careful about the label. The project says the root cause lies outside sshd but is exploitable through it, which is why the fix ships in sshd rather than in musl. The release notes call the change a workaround, not a repair of the underlying library behaviour.
Alpine's fix for stable branches is a backport rather than a jump to 10.6p2. Each supported branch carries a patched build of its existing OpenSSH version, which is why the fixed package numbers differ from branch to branch. Administrators should compare the installed version with the advisory's table instead of assuming that only 10.6p2 is safe.
Why does any long password get in?
When sshd runs without PAM, it checks a password itself. It hashes the attempt with crypt(), the C library function that turns a password into its stored form, and compares the result with the field kept in /etc/shadow.
An account with no password stores a single asterisk in that field. That string is too short to contain a salt, the random prefix of a real hash. OpenSSH handles the case by borrowing the salt of another local account. The behaviour was added in July 2016 to blunt CVE-2016-6210, a timing flaw that let attackers learn which usernames existed.
musl, the C library Alpine uses, made two changes in August 2012 that set up the collision. A failed crypt() call stopped returning NULL and returned “*” instead, because too many programs failed to check for errors. A second change, later that month, capped SHA-512 crypt input at 256 bytes to prevent denial-of-service attempts.
Put the pieces together and the comparison inverts. A password longer than 256 bytes makes musl's crypt() fail, and the failure value is the same “*” stored for an account with no password. sshd sees a match and accepts the login. The upper bound is sshd's own 1,024-byte password limit.
Two details explain why the attack is reliable rather than probabilistic. The borrowed salt comes from a real hash, so the code path reaches the comparison every time. The failure string is fixed, so the result does not depend on the password's contents, only on its length.
PAM changes the path. When PAM handles authentication, an account whose password field is “*” is evaluated without a crypt() comparison, because there is no usable hash to test. That is why systems that authenticate through PAM are safe even when they use musl.
The weakness therefore has a long tail. The salt-borrowing code dates from 2016, and Alpine's use of “*” for root dates from about version 3.16 in 2022. Neither change was wrong on its own. The bypass emerged from their interaction with a libc error convention that predates both.
The fix in 10.6p2 makes sshd refuse a match when the stored field is shorter than four characters. Stable Alpine packages carry a patch for the same problem. Kültekin says the weakness has existed since the 2016 salt-borrowing change, which means roughly a decade of exposure on the right configuration.
One precondition explains why a fresh machine is not exposed. sshd needs a real $5$ or $6$ hash somewhere on the system to borrow a salt from. A server where no account carries one of those hashes does not produce the matching failure value.
Which systems are affected, and which are safe?
Alpine's advisory lists four conditions, and all four must hold. The first three match a typical Alpine server; the fourth depends on whether any local account has a real password. The first is that the server runs the openssh-server package, which is built without PAM, or runs openssh-server-pam with UsePAM set to no.
The second is that PasswordAuthentication is yes, which is OpenSSH's default. The third is that at least one account has “*” in its password field. That covers root, key-only users created without a password, and directory-service users seen through musl-nscd. The fourth is that at least one other local account has a $5$ or $6$ password hash, which supplies the salt.
Every Alpine release the project checked was affected: 3.21 through 3.24 and edge, plus the older branches from 3.16 to 3.20 that no longer receive regular updates. The project shipped fixes in 3.21.10, 3.22.8, 3.23.8 and 3.24.4. It also published patched packages for 3.16 through 3.20, even though 3.21 reached end of support on 1 November 2026.
Root has shipped as root:* since about Alpine 3.16. OpenSSH's default PermitRootLogin prohibit-password keeps direct root logins out unless an operator changed it. That protection weakens when another account can escalate. The official tiny-cloud images from 3.18.11 through 3.24.3 include an alpine user with a “*” password and passwordless doas, so one added hash can turn a default cloud image into a root path.
Several populations are clear. Systems on glibc, systems that authenticate through PAM, and non-Linux systems are not affected. Containers that do not run sshd are not affected. Servers with PasswordAuthentication no are not affected, and neither are accounts locked with “!” in /etc/shadow.
The pattern is not unique to Alpine. Kültekin's write-up names OpenWrt, Buildroot and Yocto as other musl-based systems to check. OpenWrt uses Dropbear for SSH by default, and Dropbear is not affected. The risk appears where an administrator has installed OpenSSH on those systems.
Cloud images add a separate wrinkle. Alpine notes that images configured through cloud-init are safe because cloud-init writes PasswordAuthentication no. The tiny-cloud images are the exception: they ship an alpine user with a “*” password and passwordless doas, so a later password change can expose the image.
Ubuntu, Debian, Fedora and most mainstream distributions use glibc and PAM, so their default server configuration does not reach the vulnerable path. That is also why the flaw stayed quiet for years. The combination is unusual, even if each part is ordinary.
How fast was the fix, and what does AI have to do with it?
The timeline was short. Damien Miller, an OpenSSH developer, wrote in the release announcement that the team learned of the problem the previous day. Version 10.6p2 followed on 5 November, one day after the report reached the project.
Kültekin's account of the discovery is unusually specific. He built sshd in as many configurations as he could: glibc and musl, PAM and no PAM, shadow and no shadow. He then sent about 17,600 unusual logins at those builds. Every build agreed except one, the combination of musl and no PAM.
He also credits automation for the scale. The work involved “agent swarms”, he writes on the project site, meaning groups of AI agents running the tests. That detail matters because OpenSSH is now openly discussing what fast, cheap bug discovery does to disclosure.
Public identifiers caught up quickly. The Hacker News reported on 5 November that no CVE had been assigned yet. MITRE's record is dated the same day, and it links a single OpenSSH commit, 4353fdc43ef646c43a8dda7025cc1a898caf1482, as the workaround.
The 10.6p2 release notes say the team has received many security reports, “many of which are findings from AI models or made with AI assistance”. Most do not survive a realistic threat model, the notes add, but the project welcomes those that come with triage, analysis, tests or proposed fixes.
Miller drew a direct lesson for release management. He wrote that the team has seen “rapid bug rediscovery by AI agents, sometimes within hours”. Because of that, OpenSSH now treats “long embargo periods” as dangerous and plans more frequent releases instead of batching fixes until a scheduled date.
The caveat is important. This particular bug was not the work of an autonomous model that reported itself. A human researcher directed the testing, validated the result and reported it. OpenSSH's broader point is about the pace of rediscovery, not about attributing this find to a machine.
The episode still shows how AI-assisted testing changes the economics of old code. A suspicious combination that once required a specialist's intuition can now be tried across dozens of build variants in a short campaign. The output still needs a person to separate a real bypass from a noisy failure, which is the part OpenSSH says it needs.
How should administrators check and fix a server?
On Alpine, the fix is a package update followed by a restart. Upgrading the package alone leaves the running daemon untouched, so the vulnerable code stays in memory until the service restarts.
Run apk upgrade -U -a as root, then restart the service with rc-service sshd restart. The fixed package versions are 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23, 10.0_p1-r11 on 3.22, 9.9_p2-r1 on 3.21 and 9.7_p1-r6 on 3.20. Older branches have their own patched builds, which the advisory lists.
Distributions that build OpenSSH themselves should move to 10.6p2 or carry the equivalent patch. The CVE record lists every version below 10.6p2 as affected, so a vendor build with a different version string still needs confirmation that the fix is present.
If an update has to wait, disabling password authentication closes the path. Test a key login first and keep the current session open until a new one succeeds. Then add PasswordAuthentication no to a drop-in file, check the configuration with sshd -t, and restart sshd.
Verification takes one command. sshd -T | grep -i passwordauthentication should print passwordauthentication no. The advisory's scripted instructions deliberately change every matching line, including lines inside a Match block, so review them before running them on a complex configuration.
Detection requires logs. Look in /var/log/messages for sshd lines that read “Accepted password” for an account with no password, such as root, alpine or a key-only user. Review doas use, recently created accounts, files and authorized keys on any machine that was exposed for a meaningful period.
The advisory's guidance on uncertainty is strict. “If you cannot rule out a login, treat the machine as compromised,” it says. Rebuilding from a known image removes that doubt. Cleaning a host whose keys and credentials may have been read does not.
Container users need a separate check. A container that does not run sshd is not exposed, even when its base image is Alpine. A container that does run sshd inherits the problem, and so does the host if the host itself runs Alpine with the default package.
What happens next?
As of 6 November, no exploitation had been reported. The absence of reports is not reassurance. The technical details are public, and the reproduction is simple.
Fredrik Almroth, principal security researcher at Detectify, expects probing to start quickly. He told SecurityWeek that “Shodan lists around 22 million systems with SSH open on port 22”, and noted that the real number is higher. Only a fraction run Alpine, but one connection per attempt makes broad testing cheap.
Jake Knott, head of threat intelligence at WatchTowr, told the same publication that brute-forcers would likely try the technique within days. The signal to watch is a rise in long-password attempts against SSH, not the appearance of a packaged exploit.
Patch verification matters as much as patch deployment. The fixed Alpine packages keep their branch's OpenSSH version, so a version check alone can look reassuring while the patched build is missing. Compare the package release suffix with the advisory's table, then restart the daemon and confirm the setting.
Administrators should also watch their inventories. Container base images, appliances built on Buildroot or Yocto, and embedded devices with OpenSSH installed all inherit the same library behaviour. A patch list that covers only virtual machines will miss them.
The longer lesson is about assumptions at library boundaries. sshd trusted a return value that a C library changed for good reasons. An error string chosen in 2012 became a valid match in 2026 because another component stored the same character. Reviews that stop at one project's code will not catch that class of bug.
For users, the defence is unchanged. Prefer keys over passwords, turn off password authentication where possible, and keep the SSH daemon patched and restarted. For maintainers, the OpenSSH team's decision to ship fixes faster is the part worth copying.