CVE-2026-123158 exploited on musl Linux; OpenSSH 10.6p2 fixes it

By Nathan Brooks

Previdian logged 20 SSHole exploitation attempts from 13 attacker IP addresses in nine countries between Nov. 6 and Nov. 8. The company confirmed root access on an Alpine Linux honeypot after the first attempt arrived less than nine hours after CVE-2026-123158 became public.

watchTowr and threat intelligence firm Previdian reported the in-the-wild activity over the weekend, while GreyNoise and Defused also logged attempts, according to SecurityWeek's Monday report. watchTowr said only botnets and cryptocurrency miners had used the flaw so far. That observation describes the activity seen, not the full range of actors that could reach the bug.

What makes SSHole work?

The flaw is an OpenSSH password-authentication bypass in upstream portable OpenSSH. It triggers only on Linux systems that use the musl C library and check passwords without PAM. Alpine fits that profile because its openssh-server package disables PAM by default, while OpenWrt, Buildroot and Yocto builds may also use the combination.

• Alpine Linux: The openssh-server package disables PAM by default, so its standard configuration can meet the trigger.
• Other musl builds: OpenWrt, Buildroot and Yocto builds can be exposed when they use musl and omit PAM.
• Not affected: glibc systems such as Debian, Ubuntu and Fedora; PAM configurations; Dropbear; and OpenBSD.

The condition is narrower than all OpenSSH servers, but it still spans Alpine and three named embedded build systems. The affected code lives upstream, while the trigger depends on each image's library and PAM configuration.

The flaw dates to a 2016 OpenSSH change associated with CVE-2016-6210, an earlier username-enumeration bug. That change made sshd hash a submitted password even when the account had no usable hash, borrowing another account's salt. The code path remained for years.

On musl, crypt() returns "" when hashing fails, including for passwords longer than 256 bytes. That output matches the "" stored for accounts that should never accept a password, so sshd lets the login through. Any password from 257 to 1,024 characters works under the vulnerable conditions.

The collision requires two conventions to align. Musl replaces a hashing error with a one-character marker, and OpenSSH uses the same marker for an account with no valid password. Once the values match, the guard accepts a login it should reject.

A 257-character password now succeeds where a 256-character one fails. That reverses the usual purpose of a length limit.

Exploitation requires password authentication to be enabled and at least one account with a real password hash. Accounts of particular concern include:

• The root account.
• Key-only users.
• Directory-service users.
• Alpine's default alpine user in the official AWS and Azure images, which has passwordless doas rights.

The 2016 behavior still processes a submitted secret even for accounts that should reject password authentication. An overlong value then supplies the universal failure token. The combination lets an attacker reach an account that SSH should reject.

GitHub hosts proof-of-concept code, but Preividan said those exploits remain unverified and may contain malware. Wakefield researcher Özgün Kültekin reported the bug after AI agents ran about 17,600 authentication tests.

The honeypot result confirms that the authentication sequence can produce root access at least once. It does not establish how many production hosts attackers compromised, and the telemetry measures attempts rather than confirmed victims.

Does the patch close the gap?

OpenSSH 10.6p2 fixed the issue on Nov. 5. Alpine shipped patched packages for every branch from 3.16 to edge the same day. The package coverage addresses availability, not deployment.

Updating the package does not restart the running sshd process, so administrators must restart the service themselves. OpenSSH developer Damien Miller urged operators unable to patch to set PasswordAuthentication to no or turn SSH off. Both measures close the password-login path.

As of Help Net Security's Nov. 6 report, CISA had not added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog. That status did not make the exposure theoretical; the source records live attempts and a confirmed honeypot compromise.

The immediate variable is operator follow-through: restarting sshd. Until that happens, a patched package can leave a vulnerable process running while the reported botnet and cryptocurrency-mining activity remains in the field.