OpenSSH flaw allows logins without a password on Alpine Linux: what to do now

On November 5, 2026, the OpenSSH project released Portable OpenSSH 10.6p2 to fix a password authentication bypass. Tracked as CVE-2026-123158 and nicknamed “sshole” by the researcher who found it, the flaw lets an attacker log in over SSH to certain accounts without knowing the password.

The good news: it only shows up under a specific combination of settings. The bad news: that combination is the default on a system that is extremely common in cloud servers and containers — Alpine Linux. Here is who is affected and what to do now.

What the flaw is

SSH is the protocol used to manage Linux servers remotely. On many systems, accounts that must not accept password logins (such as root on Alpine, or users who only sign in with a key) have a * instead of a password hash in /etc/shadow. By convention, no typed password can ever match that value.

According to researcher Özgün Kültekin’s write-up, the problem comes from two behaviours that each made sense on their own:

• The musl C library (used by Alpine) returns the string * when it cannot compute a password hash — for example, when the password is too long.
• When it does not use PAM, sshd compares that result with the value stored in /etc/shadow.

The result: a deliberately oversized password produces * as its “hash”, which is exactly what is stored for accounts locked against password logins, and the login is accepted. The OpenSSH release notes state that the root cause lies outside sshd, but that it is exploitable through it — which is why the fix landed in OpenSSH itself.

Who is affected

According to the researcher’s write-up, all of the following must be true:

• sshd runs on musl (Alpine Linux, OpenWrt, Buildroot, Yocto and many container images);
• sshd does not use PAM — the default for Alpine’s openssh-server package;
• Password authentication is enabled (also the default);
• At least one account has * as its password and another account has a real password.

The researcher also states that glibc-based systems (Debian, Ubuntu, Red Hat, Fedora), PAM-based setups, Dropbear and OpenBSD are not affected. The write-up also notes that Alpine’s official AWS and Azure images were exposed through their default user, which has passwordless admin rights via doas.

The flaw has a CVSS 3.1 score of 8.1 (high), according to SOC Prime’s analysis.

Is it being exploited?

Reports differ. Help Net Security reported that threat intelligence firm Previdian saw the first attack attempt less than nine hours after the CVE was published and confirmed root access on an Alpine Linux honeypot. As of that report, the flaw was not in CISA’s Known Exploited Vulnerabilities (KEV) catalog.

Proof-of-concept code is also circulating on GitHub. The same report warns that it is unverified and may contain malware — do not run it on company machines.

In practice, treat this as urgent: the gap between disclosure and the first attacks was hours, not weeks.

What to do now: checklist

1. Find musl-based systems that expose SSH. Check servers, VPSs, appliances and containers running Alpine (they have an /etc/alpine-release file). Don’t forget Docker images that ship an SSH server.

2. Update OpenSSH and restart the service. On Alpine:

apk update && apk upgrade openssh
rc-service sshd restart

The Alpine security tracker lists the fixed package for each branch (for example 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24). Check the package version, not the SSH banner: the fix was backported to older versions. And remember to restart sshd — until you do, the old process keeps accepting connections.

3. If you can’t update right away, turn off password logins. This is what the researcher recommends and, according to Help Net Security, what OpenSSH developer Damien Miller urged as well:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-password.conf
rc-service sshd restart

Make sure SSH key access works first, so you don’t lock yourself out.

4. Rebuild your container images. Rebuild them from an updated Alpine base and redeploy. Running containers do not update themselves.

5. Look for signs of compromise. List the accounts that should never accept a password and check whether any of them had a password login accepted:

awk -F: '$2=="*" {print $1}' /etc/shadow
grep "Accepted password for" /var/log/messages

An accepted password login for a passwordless account (such as root or a key-only user) is a strong sign of exploitation. Also review recently created users, authorized_keys files and doas/sudo usage.

6. If you find signs of access, treat it as an incident. Patching is not enough: an attacker may have left keys, users or programs behind to come back later. Isolate the machine, preserve the logs and, ideally, rebuild the server from a clean base.

The lesson beyond this bug

sshole shows how two reasonable decisions, made in different projects years apart, can combine into a serious hole. A few habits limit the damage of the next flaw, whatever it turns out to be:

• Use SSH keys only for administrative access and disable password logins wherever you can;
• Don’t expose SSH to the whole internet: restrict it by IP, VPN or a bastion host;
• Keep an inventory of servers and images, so you know right away where a fix needs to go;
• Monitor authentication logs and get alerts on unusual logins.

If you’re not sure which of your company’s servers are exposed, or you’d like help patching and checking your environment, take a look at our malware and vulnerability monitoring and incident response services. Or start with a diagnosis: request a free assessment and we’ll help you understand your real risk — no scare tactics.