--- title: OpenSSH 10.6p2 has been released with a workaround for a... description: OpenSSH 10.6p2 has a workaround for a critical vulnerability affecting Linux systems that use musl libc without PAM, such as Alpine Linux. Affected admins... canonical: https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability | daily.dev og:description: OpenSSH 10.6p2 has a workaround for a critical vulnerability affecting Linux systems that use musl libc without PAM, such as Alpine Linux. Affected admins... og:url: https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv og:image: https://api.daily.dev/og/posts/jmblf4EiV.png og:image:alt: OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability **[Hacker News](https://daily.dev/sources/hn)** · 3 min read · 0 upvotes · 0 comments ## Summary OpenSSH 10.6p2 has a workaround for a critical vulnerability affecting Linux systems that use musl libc without PAM, such as Alpine Linux. Affected admins should set PasswordAuthentication=no or disable SSH immediately. The bug does not affect non-Linux systems, glibc-based Linux systems, or Linux systems using PAM for password authentication. Damien Miller says the root cause lies outside OpenSSH itself but the team can deliver a mitigation quickly, citing recent rapid bug rediscovery by AI agents as a reason to shorten embargo periods. Dropbear SSH was separately confirmed unaffected by its maintainer. The flaw was reported by Özgün Kültekin of Wakefield, with Alpine Linux developers providing a quick updated release. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Am I affected by the OpenSSH musl libc vulnerability fixed in 10.6p2? Only if running a Linux system that uses musl libc without PAM, such as Alpine Linux. The vulnerability does not exist on non-Linux systems, Linux/glibc systems, or Linux systems that use PAM for password authentication. Affected systems should set PasswordAuthentication=no or disable SSH immediately until OpenSSH 10.6p2 is applied. _Track critical patches like this OpenSSH musl fix on daily.dev before attackers catch up._ ### Is Dropbear SSH affected by the same musl libc vulnerability as OpenSSH? No, Dropbear SSH is not affected. Its maintainer verified the Dropbear source code directly, specifically the password authentication handling, and confirmed the issue does not apply, even though Dropbear is commonly used on embedded systems that also run musl libc. _Compare SSH implementations like Dropbear and OpenSSH on daily.dev when hardening embedded systems._ ### Why did OpenSSH release a fix so quickly instead of using a long embargo period? The OpenSSH team shipped OpenSSH 10.6p2 the day after learning of the problem because they have observed multiple cases of AI agents rapidly rediscovering vulnerabilities, sometimes within hours. They now consider long embargo periods a dangerous practice that mainly benefits attackers rather than defenders. _Follow how AI-driven vulnerability rediscovery is reshaping disclosure norms on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 65 comments across hackernews (as of 2026-11-05). **TL;DR:** Discussion centers on the musl-specific root cause of the vulnerability, with many noting the exploit requires a narrow combination of conditions (musl, no PAM, password auth enabled, a '*' hash account alongside a real password) while others argue those conditions are common enough to matter; there's also a long tangent on password vs key authentication and disaster-recovery scenarios. **Sentiment:** 10% positive · 35% mixed · 55% skeptical **The case for** - Some argue disabling PasswordAuthentication is simply good general security practice regardless of this bug. - OpenSSH's quick mitigation and transparency about the issue was seen favorably by some. **The pushback** - Several argue the required conditions (musl + no PAM + password auth + a '*' hash account + another valid password) are all ANDed, so the practical impact is much smaller than headlines suggest. - Multiple commenters blame musl's crypt() implementation for violating POSIX behavior by returning '*'/'!' instead of NULL on error. - Some say OpenSSH itself contributes to the bug by comparing against the wrong user's hash to avoid timing attacks. - Concern that relying solely on memorized credentials or convenient recovery paths undermines security best practices. **By community** - hackernews (mixed): Technical dissection of the musl/OpenSSH interaction dominates, split between those downplaying the real-world severity and those defending the critical rating, alongside a sizable side-thread on password vs. key-based SSH auth. **Hottest debate:** Whether the vulnerability's narrow, ANDed preconditions mean it's being overhyped as 'critical' versus genuinely widespread given how common those conditions (like Alpine's defaults) actually are. **Open questions** - Is the exploit actually reliably triggerable on default Alpine installs given its use of '!' rather than '*' as the shadow placeholder? - Will OpenBSD's 'two remote holes' security track record need updating given this bug touches OpenSSH on Linux? - Should this incident push embargo/disclosure norms to shorten further given AI-driven bug rediscovery? **Highlights** > Maybe I'm misunderstanding, but u/tonnydourado pointed out on another thread https://news.ycombinator.com/item?id=50378228#50380029 "It starts with a bold claim: "ssh accounts that should not accept a password will accept any password between 256 and 1024 characters". But then it keeps adding qualifiers: - sshd compiled with musl - not using PAM - password logins enabled - at least one account with '*' as the password "hash" - at least one OTHER account with a valid password The conditions are all ANDed, miss a single one and you're fine." This doesn't seem to be nearly as big as an issue as they're making it out to be > — [dpoloncsak on hackernews · 2 comments](https://news.ycombinator.com/item?id=50380189) > Alpine matches the first. Disabling PAM has been "generally good security advice" for decades; I remember suggestions to not use it in the 2000s. Password logins are often enabled, especially on multi-user and default setups. If alpine uses the * feature, it's going to be pretty common. Gentoo has it, as does Ubuntu. If password logins are enabled, you're almost guaranteed to have at least one user with a password (root on all my boxes has one, even if I never use it and it's random garbage). So the cheese lines up pretty well, this affects quite a bit. If password logins are enabled, someone almost certainly has a password. > — [bombcar on hackernews](https://news.ycombinator.com/item?id=50380335) > Well, OpenSSH contributes to this by mixing hashes from the shadow file. The musl code would be correct if OpenSSH passed in the hash from the user account that is being logged-in. They instead pass in a different user’s hash (to avoid timing attacks) but end up comparing the result from musl against the actual user account, defeating musl’s simplistic safeguard to avoid this very issue. I’d probably still call this a musl thing. Errors should result in a NULL return even if the application crashes from there, but at the very least a return value intended to not match any actual hash in /etc/shadow should be a random string or predefined UUID or something other than *. > — [mpyne on hackernews · 1 comments](https://news.ycombinator.com/item?id=50379447) > musl libc violates the POSIX documented behavior of `crypt()`¹ > Upon successful completion, crypt() shall return a pointer to the hashed password; the first two bytes of the returned value shall be those of the salt argument. Otherwise, it shall return a null pointer and set errno to indicate the error. Musl returns '!' or '*', not null. ¹https://pubs.opengroup.org/onlinepubs/9799919799/ > — [SAI\_Peregrinus on hackernews](https://news.ycombinator.com/item?id=50380199) > Wow, what a bug. I expect the exploit is literally as simple as trying to ssh in as a user with the password has ‘*’ in /etc/shadow and typing anything as the password. To the extent that systems that are configured in the vulnerable manner exist in the wild, I’m surprised they weren’t exploited years ago by trivial ssh bots. P.S. Wow, I’m reminded of just how awful traditional UNIX-y C APIs and code are. P.P.S. The musl code in question is nuts. The API it implements is awful. Seriously, here’s the manpage: https://man.archlinux.org/man/crypt.3.en You can’t call this function correctly. sshd’s “fix” is basically to assume that a too-short return is an error return instead of a success return. PAM is also awful, but this is worse. > — [amluto on hackernews · 1 comments](https://news.ycombinator.com/item?id=50378099) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50377221) · 136 points · 65 comments ## Similar posts on daily.dev - [Critical Remote Code Execution Vulnerability in libssh2 Client Library Require Urgent Mitigation](https://daily.dev/posts/critical-remote-code-execution-vulnerability-in-libssh2-client-library-require-urgent-mitigation-uak3prjwd) · Arctic Wolf · 0 upvotes · 0 comments - [libssh2 CVE-2026-55200 Shows Why Outbound SSH Is an Attack Surface](https://daily.dev/posts/libssh2-cve-2026-55200-shows-why-outbound-ssh-is-an-attack-surface-pza5y7nfo) · Latest Hacking News · 1 upvotes · 0 comments - [Trojaned OpenSSH](https://daily.dev/posts/trojaned-openssh-1b563evx6) · Lobsters · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#linux](https://daily.dev/tags/linux), [#ssh](https://daily.dev/tags/ssh) [View this post on daily.dev](https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability","url":"https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv"},"datePublished":"2026-11-05T13:35:01.095Z","dateModified":"2026-11-05T21:43:06.843Z","description":"OpenSSH 10.6p2 has a workaround for a critical vulnerability affecting Linux systems that use musl libc without PAM, such as Alpine Linux. Affected admins...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,linux,ssh","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/openssh-10-6p2-has-been-released-with-a-workaround-for-a-critical-vulnerability-jmblf4eiv#faq","mainEntity":[{"@type":"Question","name":"Am I affected by the OpenSSH musl libc vulnerability fixed in 10.6p2?","acceptedAnswer":{"@type":"Answer","text":"Only if running a Linux system that uses musl libc without PAM, such as Alpine Linux. The vulnerability does not exist on non-Linux systems, Linux/glibc systems, or Linux systems that use PAM for password authentication. Affected systems should set PasswordAuthentication=no or disable SSH immediately until OpenSSH 10.6p2 is applied. Track critical patches like this OpenSSH musl fix on daily.dev before attackers catch up."}},{"@type":"Question","name":"Is Dropbear SSH affected by the same musl libc vulnerability as OpenSSH?","acceptedAnswer":{"@type":"Answer","text":"No, Dropbear SSH is not affected. Its maintainer verified the Dropbear source code directly, specifically the password authentication handling, and confirmed the issue does not apply, even though Dropbear is commonly used on embedded systems that also run musl libc. Compare SSH implementations like Dropbear and OpenSSH on daily.dev when hardening embedded systems."}},{"@type":"Question","name":"Why did OpenSSH release a fix so quickly instead of using a long embargo period?","acceptedAnswer":{"@type":"Answer","text":"The OpenSSH team shipped OpenSSH 10.6p2 the day after learning of the problem because they have observed multiple cases of AI agents rapidly rediscovering vulnerabilities, sometimes within hours. They now consider long embargo periods a dangerous practice that mainly benefits attackers rather than defenders. Follow how AI-driven vulnerability rediscovery is reshaping disclosure norms on daily.dev."}}]} ```