Some implementations of secure shell (SSH), one of Linux’s most trusted and secure connection protocols, have been found vulnerable to the most peculiarly simple methods of bypass: spamming characters.
On some distros, simply type 257–1,024 characters and you get access to the root (admin) login. Thankfully, the list of vulnerable distros is quite small and niche, and OpenSSH has already issued a workaround/fix.
In some new release notes, OpenSSH explains that “this release contains a critical security workaround that affects Linux systems that use the musl libc and PAM disabled.”
Latest Videos FromPC Gamer
“Sshd(8): avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled. We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.”
SSH itself is a longstanding and ubiquitous networking protocol that anyone who has dabbled even lightly in Linux networking projects will be familiar with. It’s what manages comms between Linux machines. If you’ve ever used a Raspberry Pi remotely, for instance, you’ll likely have logged into it using SSH. Same goes for a NAS. It’s also used by devs to push/pull/manage GitHub files.
Thankfully, it’s not SSH in general that has the problem but just a small number of distros that use SSH.
According to an explanation on sshhole.com—a website written by Ozgun Kultekin who discovered the bug—this is an issue with “musl Linux.”
This refers to any Linux OS that uses the musl C library rather than the standard Glib C library, which is a fancier way of saying: not many distros.
Most distros don’t use musl, but a few do. Perhaps most prominently, Alpine Linux, a minimal, security-focused distro. As OpenSSH clarifies, it’s also not just musl Linux distros in general, but only those running SSH servers that have Pluggable Authentication Module (PAM) support disabled.
The background as to why this bug occurs and why it was overlooked is pretty complicated, involving different login security functions developed for different purposes overlapping with this specific kind of edge case being overlooked. Sshhole.com explains it better than I can.
The long and short, though, is that one function used * (a star) as a value under the assumption that it would never be used as a password hash, because that usually cannot happen. But another completely separate function, after some further shenanigans, makes the password hash a star if it’s ‘invalid’ because the password has too many characters.
Thus: Spam letters, get let into root.
Most Linux users are absolutely fine. As the bug researchers explains: “On debian, ubuntu, fedora or anything else with glibc? going through pam? dropbear? openbsd? you’re fine.”
Here are the set of conditions you need to fall under to not be fine:
- “Is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
- is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
- are password logins still on? they are by default
- is there an account with just * as its password? key-only users, ldap users, root on alpine
- and some other account with a real password?”
Though for my part, and although this might not be warranted, I’ll be considering this will a justification for sticking to the bigger distros. Ubuntu, Fedora, and so on. Or Windows, I suppose. Good things are still happening over in closed-source land.
Best gaming rigs 2026
