MAG212 CYBER ORIGINAL ARTICLE

CVE-2026-123158 (“sshole”): OpenSSH Password Bypass on musl Linux Hits Alpine; Fixed Versions and Workaround

November 6, 2026 · El Mostafa Ouchen

MAG212 CYBER | Critical CVEs | November 6, 2026

CVE-2026-123158, nicknamed “sshole”, is a password-authentication bypass in OpenSSH that affects Linux systems built with the musl C library and running sshd without PAM. On those systems, a password of 257 bytes or more can log in to accounts that have no password at all. Alpine Linux is the most prominent affected platform. OpenSSH shipped 10.6p2 on 5 November as an urgent workaround, and Alpine published patched packages for every branch back to 3.16 the same day. One honeypot operator now reports exploitation, a claim other trackers have not confirmed.

Key facts

Item	Detail
CVE	CVE-2026-123158 (CNA: MITRE; published 5 Nov 2026, updated 6 Nov)
Severity	CVSS 3.1 8.1 High per the CVE record (`AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`)
Weakness	CWE-394, Unexpected Status Code or Return Value
Affected	OpenSSH 7.3p1 through 10.6p1 on musl Linux, built or run without PAM, with `PasswordAuthentication` enabled (the default)
Fixed upstream	OpenSSH 10.6p2, released 5 November 2026
Exploitation	One vendor (Previdian) reports eight attempts and root on a honeypot; Orca, GBHackers and Safe Security reported no in-the-wild exploitation
CISA KEV	Not listed; CISA’s SSVC assessment says exploitation status “poc”
Researcher	Özgün Kültekin, Wakefield

How the bypass works

The researcher describes the bug as three reasonable changes, made in three projects years apart, that combine into an authentication bypass. Here is the sequence on an affected server.

No PAM, so sshd checks passwords itself. When OpenSSH is built or run without PAM, sshd hashes the submitted password with crypt() and compares the result, string for string, against the account’s stored shadow field.
The account has no real hash. Key-only accounts commonly have a password field of exactly *. sshd has compared against that value since the 1990s.
sshd borrows a salt. A field that short cannot hold a salt. Since 2016, as part of the fix for the timing leak CVE-2016-6210, sshd borrows the salt from another local account that has a SHA-256 ( $5$ ) or SHA-512 ( $6$ ) hash, so that failed logins for passwordless accounts take as long as real ones.
musl rejects the long key. Since 2012, musl’s SHA-crypt has refused keys longer than 256 bytes, a cap added to prevent denial of service. On failure it returns an error string consisting of a single asterisk.
The strings match. sshd compares that error output with the stored field. Both are the one-character string *, the comparison succeeds and the login is accepted.

The third ingredient is on Alpine’s side: in 2022 Alpine changed root’s password field so that SSH key logins would work again, which is why root ships with that one-character field.

About the password length. Sources word the threshold differently. The Alpine advisory, the researcher and the proof of concept say 257 to 1,024 bytes; the PoC shows a 256-character password rejected and a 257-character one accepted on Alpine 3.24. The CVE record says “between 256 and 1024 characters”, and the oss-security summary says “longer than 257 characters”. The PoC evidence supports 257 to 1,024. None of the sources we checked explains where the 1,024-byte upper bound comes from. GBHackers describes practical exploitation as a wrong password first, then roughly 300 “A” characters.

Across about 17,600 unusual login attempts against many sshd builds, only the musl build without PAM accepted logins it should have refused. OpenSSH’s release notes put it this way: “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.” The upstream fix makes sshd skip the comparison when the stored field is too short to be a real hash, and stops using a pointer into libc’s static buffer.

On oss-security, Michael Orlitzky wrote that crypt(3) error behaviour “isn’t well standardized” and that authenticating with strcmp on its output is “optimistic”; Vincent Lefevre countered that checking error conditions is the application’s job.

Who is affected

All of these conditions must hold:

The server runs musl libc and OpenSSH without PAM.
Password authentication is enabled, which is the OpenSSH default.
At least one account has a password field of exactly *.
At least one other account has a real $5$ or $6$ hash. In Alpine’s words, “One password-bearing user is enough to expose every account without one.”
The attacker can reach the SSH port.

On Alpine 3.16 to 3.24 and edge, that means the openssh-server package (built without PAM), or openssh-server-pam with UsePAM no. Exposed accounts include:

root, which has shipped with that one-character field since about 3.16. The default PermitRootLogin prohibit-password protects it, but an attacker who gets in as another user can still reach root through doas.
Key-only users created without a password or with usermod -p '*'.
Directory-service users (nslcd, winbind, sssd) served through musl-nscd, which have no shadow entry.
The alpine user in official tiny-cloud images. Alpine’s qcow2, VHD and AMI images 3.18.11 through 3.24.3 include this user with no password and passwordless doas. These images are safe on first boot. They become exploitable once any $6$ hash exists on the host, for example when an admin sets a console password or user-data adds a user with hashed_passwd. An attacker then gets a shell as alpine and uses doas to become root. Images from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward include the fix.

The researcher also lists OpenWrt, postmarketOS, Void Linux (musl), Chimera, and Buildroot and Yocto builds with musl, and has flagged “a lot of the docker images” people have pulled. No advisory or fixed version had been published for any of these in the sources we checked. Orca, Brandefense and Safe Security likewise report no non-Alpine distribution fixes.

Who is not affected

glibc distributions: Debian, Ubuntu, Fedora, Red Hat, SUSE and others.
OpenSSH running with PAM, including Alpine’s openssh-server-pam with UsePAM yes.
Non-Linux systems: OpenBSD, FreeBSD, macOS.
Dropbear.
Servers with PasswordAuthentication no. Alpine says cloud-init instances write this setting and are not affected.
Locked accounts whose field is !.
Containers that do not run sshd, and systems with no $-style hashes at all.

Exploitation: what has and hasn’t been seen

Help Net Security reported on 6 November that Previdian observed exploitation. According to that report:

The first attempt came less than nine hours after the CVE was published.
There were eight attempts in total, all from one Japan-based IP address, 89.116.89[.]18, all caught by a single sensor.
The attacker used oversized passwords and gained root on a honeypot running real Alpine Linux and OpenSSH, then ran reconnaissance commands (id, uname, hostname) over non-interactive SSH sessions.
Founder Ryan Dewhurst said the flaw is especially easy to exploit, which he believes shortened attacker timelines, partly through AI assistance.

Treat this as a single-vendor, single-sensor report. We could not access Previdian’s own post, and we found no independent confirmation. The report does not say how the attacker reached root on the honeypot. Orca (5 November) said no exploitation in the wild had been reported, GBHackers (6 November) said the same, and Safe Security said confirmed in-the-wild exploitation “had not been established”.

Proof-of-concept code is public, including the researcher’s own Docker-based lab and check script. Previdian warns that other GitHub PoCs are unverified and may contain malware. Don’t run them on systems you care about.

CISA has not added CVE-2026-123158 to KEV. Its SSVC assessment in the CVE record rates exploitation “poc”, automatable “no” and technical impact “total”. Hong Kong’s GovCERT.HK issued High Threat Security Alert A26-11-09 urging an immediate update; HKCERT rated the issue Medium risk.

Fixed versions

Upstream, the fix is OpenSSH 10.6p2. The patch applies to every release from 7.3p1, and the researcher’s repository carries it for older versions.

Alpine’s fixed openssh packages:

Branch	Fixed version
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	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Only edge moves to 10.6p2. The stable branches carry a backported patch on their existing OpenSSH version, so don’t judge exposure by the upstream version number alone. Alpine 3.21 reached end of support on 1 November, but fixed packages were still published for every release back to 3.16. The fixed point releases are 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

How to check and fix

These commands are for Alpine and run as root. We checked them against the Alpine advisory and OpenSSH documentation but did not run them on an affected host.

Read-only checks. List the installed OpenSSH packages and compare them with the table above, then see what the running configuration does:

apk list --installed 'openssh*'
sshd -T | grep -Ei '^(passwordauthentication|usepam|permitrootlogin) '

Look for password logins on accounts that should not have a password, such as alpine, root or key-only users:

grep 'Accepted password for' /var/log/messages

Change: upgrade and restart. An upgrade does not replace the running daemon, so restart sshd afterwards. Alpine’s advisory recommends upgrading the whole system with apk upgrade -U -a; to update OpenSSH alone:

apk update
apk upgrade openssh
rc-service sshd restart

Change: workaround if you can’t patch yet. Confirm that key login works and keep an existing session open before you restart. Set PasswordAuthentication no in /etc/ssh/sshd_config, or in a drop-in under /etc/ssh/sshd_config.d/ as Alpine suggests (the default config reads it from 3.19), then test and restart:

# in /etc/ssh/sshd_config or /etc/ssh/sshd_config.d/
PasswordAuthentication no

sshd -t
rc-service sshd restart
sshd -T | grep -i '^passwordauthentication '

The researcher says this setting closes the issue completely. Damien Miller of OpenSSH was blunter in his openssh-unix-dev post: on Linux systems using musl without PAM, such as Alpine, “set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.” He said the release was rushed because the team learned of the problem the previous day, and argued that long embargoes now carry more risk because AI agents have rediscovered bugs within hours.

If you find a suspicious login, review doas usage, new users, new files and authorized keys. If you can’t rule out a bypass login, treat the host as compromised.

Timeline

3 November: Wakefield finds the bug and reports it to OpenSSH; a patch follows in under an hour, per the researcher. (Miller describes learning of it “the previous day” relative to 5 November; the gap may reflect time zones or triage timing.)
4 November: Alpine and musl maintainers are notified.
5 November: OpenSSH 10.6p2 is released, Alpine publishes fixed packages and its advisory, and the research goes public. MITRE publishes CVE-2026-123158 at 15:46 UTC.
6 November: The CVE record is updated. GovCERT.HK and HKCERT issue alerts, Help Net Security reports Previdian’s exploitation claim, and the oss-security debate over crypt() error semantics continues.

Frequently asked questions

Is my Ubuntu or Debian server affected by sshole?

No. The bug needs musl libc and sshd without PAM. glibc distributions such as Debian, Ubuntu, Fedora, Red Hat and SUSE are not affected.

Which Alpine version fixes CVE-2026-123158?

Check the openssh package version, not the upstream release. For example, 3.24 is fixed in 10.3_p1-r2 and edge in 10.6_p2-r0. Restart sshd after upgrading.

Is CVE-2026-123158 being exploited?

One vendor, Previdian, reports eight attempts from a single IP and root on a honeypot. Other trackers had reported no in-the-wild exploitation, and CISA had not added the flaw to KEV as of 6 November.

Does disabling password authentication fully fix it?

The researcher says PasswordAuthentication no closes the issue completely. It’s a workaround, though; install the fixed package as well.

Sources

This article expands a story from the MAG212 CYBER Daily, 6 November 2026. Related: Tailscale SSH vulnerabilities and hardening.

Read the full magazine (PDF) →