National Cyber Warfare Foundation (NCWF)

On November 5, 2026, Alpine Linux published a security advisory for an authentication bypass in its openssh-server package, nicknamed sshole by researcher Özgün Kültekin of ...

The post Critical vulnerability: OpenSSH authentication bypass on Alpine Linux appeared first on Blog Detectify.

On November 5, 2026, Alpine Linux published a security advisory for an authentication bypass in its openssh-server package, nicknamed sshole by researcher Özgün Kültekin of Wakefield, who reported it. An attacker who can reach the SSH port can log in to accounts that have no password set, such as key-only users, without knowing any password. Every Alpine release from 3.16 through 3.24 and edge is affected. No CVE identifier has been assigned yet.

Fixed packages are available. Detectify recommends updating OpenSSH or disabling password authentication right away.

What is the risk?

Accounts with no password have a * in place of a password hash. On Alpine’s default OpenSSH build, which does not use PAM, sshd checks passwords with musl’s crypt() function. When the password is longer than 256 bytes, crypt() returns * as its error value. That matches the stored *, so sshd lets the attacker in.

Easy to exploit: The attacker needs no password and no special tools, only the name of a suitable account.

Can lead to root: On the official Alpine cloud images, the alpine user can become root through passwordless doas once the system is exploitable.

Limited exposure: The bug only works under a specific set of conditions (see below), and most Linux systems are not affected.

Exploitation status: As of November 5 at 15.30h CET, Detectify is not aware of public reports of exploitation. Since the details are public and the attack is simple, we expect scanning attempts to follow.

Are you affected?

You are affected if all of these conditions are true:

You run Alpine’s openssh-server package, or openssh-server-pam with UsePAM no.

PasswordAuthentication is set to yes, which is the OpenSSH default.

The machine has an account whose password field is *. This includes key-only users, directory users through musl-nscd, and the alpine user on official cloud images. Root also has * by default, but the default PermitRootLogin prohibit-password setting protects it.

At least one other local account has a real (5 or 6) password hash.

Cloud images: the official Alpine cloud images (3.18.11 through 3.24.3) are safe on first boot. They become exploitable once any account gets a password, for example when an admin sets a console password.

Not affected: containers that don’t run sshd, systems with PasswordAuthentication no, openssh-server-pam with UsePAM yes, images configured through cloud-init, locked accounts with ! as the password field, and non-musl systems such as Debian, Ubuntu and Fedora.

What are we doing?

Detectify is currently building a new assessment engine that runs tests over SSH and other non-HTTP protocols to test customer attack surfaces for vulnerabilities like this one.

Detectify’s Surface Monitoring maps your internet-facing assets and the services running on them, such as SSH, to help you find exposed systems you may not know about.

How to mitigate the threat

Update and restart sshd. Run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package does not restart the running daemon. Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix, and Alpine has published fixed packages back to 3.16.

Disable password logins if you can’t update yet: set PasswordAuthentication no in your sshd configuration and restart sshd. Make sure your SSH key login works first.

Check for compromise: look in /var/log/messages for Accepted password entries for accounts with no password, such as alpine, root or key-only users. Also review doas use and recently created users, files and authorized keys. If you can’t rule out a login, treat the machine as compromised.

Limit SSH exposure: avoid exposing SSH directly to the internet where possible.

How to check if you were attacked

Run these two commands on any exposed machine. The first lists successful password logins, and the second shows the password field of the account that logged in (here, alpine):

$ grep "Accepted password" /var/log/messages
Nov  2 03:14:07 your-box sshd[2211]: Accepted password for alpine from 203.0.113.66 port 41822 ssh2

$ grep '^alpine:' /etc/shadow
alpine:*:20125:0:99999:7:::

If you see a match like this, an account with no password (*) just accepted a password login. Repeat the second command for each account that shows up in the first, such as root or key-only users.

On exposed machines, also review doas use and recently created users, files and authorized keys.

If you can’t rule out a login, treat the machine as compromised.

References

sshole disclosure (sshhole.com)

Damien Miller (OpenSSH) announcement

Security advisory: openssh-server password authentication bypass

OpenSSH release notes