OpenSSH “*sshole” flaw lets attackers into password-locked Linux accounts: is your server affected?
A decade-old OpenSSH bug lets attackers log into some password-disabled accounts on musl-based Linux systems like Alpine just by sending a very long password. Here's who is affected and how to fix it.
A security bug nicknamed “*sshole” in OpenSSH, the software used to log into Linux servers remotely, can let attackers into accounts that are supposed to have password logins turned off. The trick is surprisingly simple: send a very long password.
The good news: it only affects certain Linux systems, and there’s already a fix. Security researcher Ozgun Kultekin disclosed it, and it was reported by BleepingComputer on November 5, 2026.
Who is affected?
Only OpenSSH servers on Linux systems that use the musl C library, such as:
- Alpine Linux, which is very popular for containers and cloud servers
- OpenWrt (routers and network devices)
- Buildroot and Yocto (embedded and IoT devices)
Not affected: Debian, Ubuntu, Fedora and other systems that use the glibc library, and any system using PAM authentication.
All of these must be true for an attack to work
- The system uses musl.
- PAM is disabled (the default in Alpine’s openssh-server package).
- SSH password login is enabled.
- At least one account is “locked” with
*as its password hash. - At least one other account has a real password.
How does the bug work? (simple version)
On Linux, a locked account often has just a * stored instead of a real password. Back in 2016, OpenSSH was changed to check passwords even for locked accounts, to stop attackers guessing which usernames exist.
Here’s the problem: on musl systems, the password-checking function also returns * when it fails, for example when a password is longer than 256 characters. So when an attacker sends a super-long password, the result is *, which matches the locked account, and the attacker gets in.
A locked door that opens when you push it hard enough: a tiny mismatch between two pieces of software created a real security hole.
Why it can be serious
Alpine’s official images for AWS and Azure include a default “alpine” account that can run admin commands without a password. If that account is locked with * and password logins are on, an attacker could gain full control (root) of the server.
It does not let attackers into accounts that have real passwords.
How to fix it
- Update OpenSSH to version 10.6p2. On Alpine:
apk upgrade openssh - Can’t update right away? Turn off password logins: set
PasswordAuthentication noin/etc/ssh/sshd_config, then restart SSH. Use SSH keys instead, which is good practice anyway.
How to check if someone got in
- Look for successful password logins on accounts that shouldn’t allow them. On Alpine:
grep "Accepted password" /var/log/messages - Check whether the default account is locked with
*:grep '^alpine:' /etc/shadow - If you find suspicious logins, treat the server as compromised: rotate keys and secrets, and consider rebuilding it.
Found with AI agents
Kultekin found the flaw using AI agents that ran about 17,600 login tests. It’s another example of AI helping researchers find old bugs faster, a trend we’ve seen all month. Read: critical GitLab flaw being exploited.
Frequently asked questions
What is the OpenSSH “*sshole” flaw?
A bug that lets attackers log into password-locked accounts on musl-based Linux systems by sending a password longer than 256 characters.
Is Ubuntu or Debian affected?
No. Systems using glibc, such as Debian, Ubuntu and Fedora, are not affected.
Which OpenSSH version fixes it?
OpenSSH 10.6p2. On Alpine, run apk upgrade openssh.
How can I protect my server without updating?
Set PasswordAuthentication no in your SSH server settings and restart SSH, and use SSH keys to log in.
