OpenSSH 10.6p2 Emergency Fix: Passwords Longer Than 256 Bytes Unlock Locked Accounts on musl Systems

Forum topic · QianXun · 2026-11-06

Summary

On November 5, 2026, Alpine Linux issued a security advisory and OpenSSH released 10.6p2 to fix a vulnerability (CVE-2026-123158, CVSS 3.1 8.1 HIGH) affecting Alpine 3.16 through 3.24 and edge. On systems using musl without PAM and with password authentication enabled, a password of 257–1024 bytes causes musl's sha512crypt to fail; musl returns an asterisk as the error value, which matches the asterisk stored in locked account fields, allowing login to accounts meant to be password-less. Attackers must also borrow a salt from an account with a real password and make a failed login attempt first. On Alpine's default AWS and Azure images, the 'alpine' user has passwordless doas, enabling privilege escalation to root; direct root login remains blocked by PermitRootLogin prohibit-password. Fixed point releases are 3.21.10, 3.22.8, 3.23.8, and 3.24.4, followed by rc-service sshd restart. The OpenSSH 10.6p2 release notes also state that many recent reports came from AI models or AI-assisted researchers, and that the project will temporarily release more frequently because AI-flagged bugs are often independently rediscovered. Reproduction and audit repositories include leonjza/sshhole-lab, predkambrij/sshhole-repro, and schappim/sshole-audit.

Security: A Password Longer Than 256 Bytes — A Key Cut in 1980 That Finally Turned in 2026

On November 5, 2026, Alpine Linux published a security advisory and OpenSSH released 10.6p2, both addressing the same flaw: in the musl world, an account marked as never allowing password login could be entered with a sufficiently long password. The length threshold is 257 characters (bytes).

CVE Details

CVE-2026-123158, assigned by MITRE on November 5; CVSS 3.1 base score 8.1 HIGH, vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-394.
When the Alpine advisory was first published it still said "No CVE identifier had been assigned at the time of writing"; the number came later that day. NVD status is "Received" with no score of its own.
Affected: Alpine 3.16 through 3.24 plus edge.
Fixed point releases: 3.21.10, 3.22.8, 3.23.8, 3.24.4.
After upgrading, run rc-service sshd restart — apk upgrade alone is not enough.

How the Chain Fit Together

Each link was innocent on its own:

1980 — Bill Joy introduced the asterisk in /etc/passwd as a "no entry" marker: an asterisk is not the hash of any password, so nothing matches. (A field value, not a piece of code — and the original post's "four pieces of code" count is loose, since its own timeline also lists a 2022 link.)
August 2012, musl change 1 — crypt failures stopped returning NULL and returned an asterisk instead, to avoid crashing careless callers.
August 2012, musl change 2 — sha512crypt gained a 256-byte password cap to keep long passwords from pegging the CPU. Overly long passwords therefore always "fail," and the failure value is exactly that asterisk.
2016 — the CVE-2016-6210 timing side-channel fix made accounts without a hash also compute a hash of the submitted password using a borrowed salt, to avoid revealing whether an account exists. The computed result compared equal to the stored asterisk — login succeeded.
2022 — Alpine 3.16 changed root's password field from ! to *, making root the asterisk account.

"Forty-six years without anyone stepping on the mine" is rhetoric: the exploitable combination only became possible after 2016 and was only in place after 2022. The disclosure page itself says "ten quiet years" (2016–2026) and repeatedly qualifies with "as far as anyone knows."

Trigger Conditions

All must hold (the official Alpine list is four items; the sixth — one failed login attempt to wake the comparison logic — appears only on the disclosure page, as "needs a wrong try first"):

1. A musl-based system 2. PAM not enabled 3. PasswordAuthentication yes 4. An account whose shadow entry is only an asterisk, plus at least one account with a real password (to borrow the salt) 5. (Disclosure page) One wrong login attempt first

A freshly installed machine is safe. glibc systems, PAM-enabled setups, Dropbear, and containers without sshd are out of scope.

"Straight to Root" — Not Quite

The claim that the door opens "directly to root" overstates it. Default PermitRootLogin prohibit-password blocks direct root login. The real path: log in as the default user alpine, then escalate via passwordless doas. Alpine's official AWS and Azure images happen to configure exactly that — the worst bit of luck in the whole chain.

Note on units: the effective range is 257 to 1024 bytes, not characters. The CVE record says "between 256 and 1024 characters," which risks making people think 257 CJK characters suffice.

Circumstantial Evidence

2013: a Debian developer proposed making glibc mimic musl's behavior in bug #714219 — if it had passed, today would look very different.
2019: Debian moved to libxcrypt, whose failure return is "asterisk zero" — one character apart.
December 2024: the musl mailing list discussed busybox's passwd breaking at 257 characters; no one mentioned sshd.
October 30: OpenSSH's own security review fixed a issue near pick_salt — this hole sat four lines away.

The Heavier Point: OpenSSH Changes Its Release Cadence

The 10.6p2 release notes state that many recent security reports came from AI models or AI-assisted researchers; most are not security issues under realistic threat models, but the team welcomes such reports provided they include human triage, analysis, and test cases. Then the heavier line: it has repeatedly happened that a bug flagged by an AI tool was independently found by another researcher, indicating that adversaries who do not report to open source projects are *likely to be able to* find the same issues. (The original post turned "likely to be able to" into a certainty — it is a probability, not a fact.) OpenSSH therefore decided to temporarily release more frequently instead of stockpiling fixes for the next planned version.

A discoverer's note worth quoting: "i had agent swarms. a lot of them." Ozgun Kultekin (Wakefield) compiled sshd in every combination he could think of — glibc and musl, with and without PAM, with and without shadow — and had agent clusters throw roughly 17,600 malicious login attempts at them. Only the musl-plus-no-PAM combination responded.

Corrections on Sourcing

The claim that the 1980–2026 timeline was "cross-verified by release notes and advisories" does not hold. The Alpine advisory and OpenSSH 10.6p2 release notes contain only the mechanism core — crypt returning an asterisk, salt borrowing, fix, conditions, versions. Everything else (1980/Bill Joy, the two 2012 musl commits, Debian bug #714219, 2019 libxcrypt, the 2024 musl mailing list, the pick_salt four lines, 17,600 attempts, agent swarms, no known exploitation) comes solely from the sshhole.com disclosure page and its cited primary sources — a single-source narrative.

Likewise, the detection repository oz9un/sshole could not be found; verifiable reproduction and audit repositories are leonjza/sshhole-lab, predkambrij/sshhole-repro, and schappim/sshole-audit. The HN "2296 points" figure lacks an item id; at capture time, thread 50378228 showed 2869 points and 698 comments — 2296 was likely an early snapshot.

Takeaway

An open source project has publicly admitted that vulnerability discovery speed now exceeds its planned release cadence. Attackers and defenders share the same accelerator. For your own Alpine containers, you can turn off PasswordAuthentication today. The door has been re-locked — but the fact that someone else once cut a key to it is worth remembering.

> The first principle is that you must not fool yourself — and you are the easiest person to fool.

Sources and caveats: sshhole.com disclosure page (Ozgun Kultekin, Wakefield; the 17,600 login tests, agent-swarm quote, and four-line distance come from that page); OpenSSH 10.6p2 official release notes (2026-11-05, musl/no-PAM workaround and AI-report cadence statement); Alpine Linux security advisory, 2026-11-05; musl commits b3c4cc12 and 88bf5a8a, CVE-2016-6210, CVE-2019-5021, Alpine 3.16 aports fbe926af, Debian bug #714219, libxcrypt's asterisk-zero — all sourced from the disclosure page timeline; "no known exploitation" is per the disclosure page's own scope.