musl only, the quick fix: PasswordAuthentication=no Which is a good advice in general.
phoronixrly
I presume Dropbear, thus musl-based OpenWrt routers are also not affected? Not that Dropbear has been an example in that regard.
crest
I'm sure some people running lightweight containers just had a heart attack.
jordiburgos
Workaround? Why not a fix?
entuno
Seems slightly confusing that the OpenSSH release notes page says: > This release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled. But that there's nothing about it on their security page. Even if it's not technically a bug in their code, the fact that they've made a "critical" release to address it suggests that it should probably be listed on the security page as well. But maybe (hopefully) they just haven't updated the security page yet.
asdfsa32
Who does PasswordAuthentication=yes in this day and age anyway.
amluto
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.
jmclnx
>We consider the root cause of this bug to be outside OpenSSH itself, but we're in a good position to deliver a mitigation quickly. So not a ssh issue but an issue specific to Linux using "musl libc without PAM".
K0nserv
This looks terrible for musl, what a collection of terrible decisions on their part. I guess I'm staying away from it.
dust42
> We are making this release as fast as possible (we learned of the problem yesterday) because we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers. I think this will likely become standard. Nevertheless, a few stormy months are ahead.
MPSimmons
Is this actually effective against Alpine? The default install seems to use ! as the placeholder in /etc/shadow instead of * and trying the attack doesn't seem to work.
zajio1am
I would say that PasswordAuthentication=yes is by itself a vulnerability.
tiffanyh
Since OpenSSH is included in the base install, and enabled on OpenBSD - is it correct that they will need to update the famous: “ Only two remote holes in the default install, in a heck of a long time! ” https://www.openbsd.org/
SV_BubbleTime
> because we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers. Seems quite reasonable. It’s quite obvious that black hats have day jobs as White hats and have been privy to embargoes for probably decades.
NewJazz
musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds. Does anyone know why musl does this? Are they the only C library that behaves this way? For a C library that famously tries to adhere to POSIX as much as possible, this seems like a crazy choice. From POSIX standard: Upon successful completion, crypt() shall return a pointer to the encoded string. 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. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
TZubiri
Here's an unrelated security issue I opened with Alpine earlier this year https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16... It didn't give me the impression that I was dealing with a secure piece of software, it seemed like they were dealing with very complex issues while laughably failing at the industry basics that were settled years ago. Similarly Ubuntu was also the only other distro that fucked this simple permissions config up, and lately with the latency to fix the TCP vuln, it seems to confirm that these are not reliable distros for the coming security era.
aborsy
I often use "AuthenticationMethods publickey" which would disable all authentications except public key. Isn't this safer than "PasswordAuthentication no", even if it's a different setting?
slopinthebag
i think it's just unbelievable there isn't a bigger push to move away from c to languages that can prevent stuff like this from happening. this and just the pure unsafety. it's 2026. it's like pure negligence at this point, the equivalent of building a bridge with matchsticks because you like using it more.
0x457
I keep saying that no one should be using alpine or musl, but people keep replying that static linking is totally worth it.
drob518
Given Alpine’s broad use in the Docker ecosystem, this is going to hit a lot of folks, I think.
Related Discussions
Found 5 related stories in 127.3ms across 11,756 title embeddings via pgvector HNSW
Discussion Highlights (20 comments)
throwa356262
musl only, the quick fix: PasswordAuthentication=no Which is a good advice in general.
phoronixrly
I presume Dropbear, thus musl-based OpenWrt routers are also not affected? Not that Dropbear has been an example in that regard.
crest
I'm sure some people running lightweight containers just had a heart attack.
jordiburgos
Workaround? Why not a fix?
entuno
Seems slightly confusing that the OpenSSH release notes page says: > This release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled. But that there's nothing about it on their security page. Even if it's not technically a bug in their code, the fact that they've made a "critical" release to address it suggests that it should probably be listed on the security page as well. But maybe (hopefully) they just haven't updated the security page yet.
asdfsa32
Who does PasswordAuthentication=yes in this day and age anyway.
amluto
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.
jmclnx
>We consider the root cause of this bug to be outside OpenSSH itself, but we're in a good position to deliver a mitigation quickly. So not a ssh issue but an issue specific to Linux using "musl libc without PAM".
K0nserv
This looks terrible for musl, what a collection of terrible decisions on their part. I guess I'm staying away from it.
dust42
> We are making this release as fast as possible (we learned of the problem yesterday) because we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers. I think this will likely become standard. Nevertheless, a few stormy months are ahead.
MPSimmons
Is this actually effective against Alpine? The default install seems to use ! as the placeholder in /etc/shadow instead of * and trying the attack doesn't seem to work.
zajio1am
I would say that PasswordAuthentication=yes is by itself a vulnerability.
tiffanyh
Since OpenSSH is included in the base install, and enabled on OpenBSD - is it correct that they will need to update the famous: “ Only two remote holes in the default install, in a heck of a long time! ” https://www.openbsd.org/
SV_BubbleTime
> because we have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers. Seems quite reasonable. It’s quite obvious that black hats have day jobs as White hats and have been privy to embargoes for probably decades.
NewJazz
musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds. Does anyone know why musl does this? Are they the only C library that behaves this way? For a C library that famously tries to adhere to POSIX as much as possible, this seems like a crazy choice. From POSIX standard: Upon successful completion, crypt() shall return a pointer to the encoded string. 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. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
TZubiri
Here's an unrelated security issue I opened with Alpine earlier this year https://gitlab.alpinelinux.org/alpine/aports/-/work_items/16... It didn't give me the impression that I was dealing with a secure piece of software, it seemed like they were dealing with very complex issues while laughably failing at the industry basics that were settled years ago. Similarly Ubuntu was also the only other distro that fucked this simple permissions config up, and lately with the latency to fix the TCP vuln, it seems to confirm that these are not reliable distros for the coming security era.
aborsy
I often use "AuthenticationMethods publickey" which would disable all authentications except public key. Isn't this safer than "PasswordAuthentication no", even if it's a different setting?
slopinthebag
i think it's just unbelievable there isn't a bigger push to move away from c to languages that can prevent stuff like this from happening. this and just the pure unsafety. it's 2026. it's like pure negligence at this point, the equivalent of building a bridge with matchsticks because you like using it more.
0x457
I keep saying that no one should be using alpine or musl, but people keep replying that static linking is totally worth it.
drob518
Given Alpine’s broad use in the Docker ecosystem, this is going to hit a lot of folks, I think.