Musl – OpenSSH password auth bypass analysis
Comments on “Musl – OpenSSH password auth bypass analysis”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Rich Felker, musl's maintainer, published a root-cause analysis of an OpenSSH password bypass affecting versions before 10.6p2 on musl when UsePAM=no and PasswordAuthentication=yes. OpenSSH uses another user's hash as salt to mask timing for locked accounts. An overlong password makes SHA256/SHA512 crypt fail, returning musl's "*" failure token, which matches a locked "*" entry. OpenSSH now rejects short hashes outright; musl may switch tokens. The claims are the maintainer's own and not independently verified.
Why it ranked
No. 3 of 107 with a score of 0.74. The panel rated it highest on technical depth (0.95) and new information (0.91), lowest on audience breadth (0.59).
- AI judgeJudge 2claude-haiku-5-5
- Detailed, primary-source mailing list post dissecting a concrete auth bypass in OpenSSH with musl; strong technical depth and security relevance, narrower audience than universal, with some non-news boilerplate.
- AI judgeJudge 3gpt-5.6-luna
- Primary maintainer analysis explains the crypt failure-token mechanism, exact OpenSSH conditions, mitigation, and fixes. It is highly actionable security material with broad server relevance, though impact depends on specific account and hash configurations.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.74total under rubric v2.3
- Significance0.65
- Reader interest0.82
- Audience breadth0.59
- Practical relevance0.80
- Substantiated0.86
- Technical depth0.95
- New information0.91
- Counts against: Promotional0.04
- Counts against: Overclaim0.12
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.60 | 0.55 | 0.78 | 0.65 | 0.23 | +0.24 | +0.155 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.72 | 0.80 | 0.93 | 0.82 | 0.21 | +0.26 | +0.212 |
| Audience breadthHow many people who build technology does it concern? | 0.55 | 0.60 | 0.62 | 0.59 | 0.07 | +0.13 | +0.077 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.75 | 0.80 | 0.86 | 0.80 | 0.11 | +0.22 | +0.177 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.80 | 0.85 | 0.94 | 0.86 | 0.14 | +0.05 | +0.043 |
| Technical depthHow technically substantive is it? | 0.99 | 0.90 | 0.96 | 0.95 | 0.09 | +0.05 | +0.048 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.90 | 0.85 | 0.98 | 0.91 | 0.13 | +0.05 | +0.046 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.08 | 0.02 | 0.01 | 0.04 | 0.07 | −0.19 | −0.007 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.16 | 0.15 | 0.04 | 0.12 | 0.12 | −0.11 | −0.013 |
| Sum of contributions | +0.737 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.737 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-07/3/"><img src="https://rubric.hrih.si/badge/2026-11-07/3.svg" alt="Ranked #3 on Rubric, 7 Nov 2026" width="231" height="28"></a>Claim check
Claim check: 1 matches source · 5 no source given · 2 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenVersion
OpenSSH versions prior to 10.6p2 using musl are affected by an authentication bypass when UsePAM=no and PasswordAuthentication=yes.
The article gives no link or citation for it.
The article says “Versions of OpenSSH prior to 10.6p2 using musl are affected by an > authentication bypass when UsePAM=no and PasswordAuthentication=yes”
The source says No source to compare with.
Couldn’t checkDate
Originally OpenSSH used root's password hash as the setting/salt when the user's hash was a single unmatchable character like "*".
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Originally they used root's”
The source says No passage could be compared.
Source cited by the article: github.com/openssh/openssh-portable/commit/9286875a73b2de7736b5e50692739d314cd8d9dc
Matches sourceDate
OpenSSH later switched to searching the user database until finding a user with a password to use as the setting/salt.
The cited source says the same thing.
The article says “and later switched to searching the user database until finding a user with a password”
The source says “by searching through accounts until we find one that has a valid 69+ * salt. Usually this will be root unless the root account is locked out”
Source cited by the article: github.com/openssh/openssh-portable/commit/dbf788b4d9d9490a5fff08a7b09888272bb10fcc
No source givenNumber
musl uses "*" as its crypt failure token, except returning "x" when the input setting is "*".
The article gives no link or citation for it.
The article says “The failure token musl uses is "*", except when the input salt/setting is "*"; in that case, it returns "x”
The source says No source to compare with.
No source givenGeneralization
OpenBSD, FreeBSD and recent Fedora return a null pointer and set errno on crypt failure, while NetBSD, musl and most glibc-based distros using libxcrypt return a failure token.
The article gives no link or citation for it.
The article says “Some implementations -- mainly OpenBSD, FreeBSD, and recent Fedora -- return a null pointer and report the condition in errno”
The source says No source to compare with.
No source givenCausal conclusion
The bypass occurs because SHA256/SHA512 crypt treats excessively long passwords as an error, so crypt(pass, some_other_hash) returns the failure token, which equals a "*" hash in the shadow file.
The article gives no link or citation for it.
The article says “for an excessively long password pass, and some_other_hash taken from a user who has a SHA256 or SHA512 hashed password”
The source says No source to compare with.
Couldn’t checkCausal conclusion
OpenSSH fixed the bug by hard-coding failure after the timing-masking crypt call, so login always fails if the target user's hash is shorter than 4 characters.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “OpenSSH fixed the bug by hard-coding failure after doing the timing-masking crypt call with the wrong hash”
The source says No passage could be compared.
Source cited by the article: github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482
No source givenGeneralization
Dropbear and other non-OpenSSH software using password-based logins is not affected.
The article gives no link or citation for it.
The article says “Dropbear and other non-OpenSSH software using password-based logins is > not affected”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 7 Nov 2026, 05:47 UTC. It played no part in the ranking.