OpenSSH 10.6p2: a long password bypasses login on Alpine

Published on November 6, 2026 · The mitza.es team

SSH is the “master key” used to administer most Linux servers: it lets you log into a machine remotely and run commands. If someone manages to bypass its password, the server is in their hands. On November 5, 2026 the OpenSSH project released version 10.6p2 and Alpine Linux published, the same day, a security advisory about a flaw of this kind. We summarize it as of November 6, 2026, sticking to what both projects have published.

What OpenSSH and Alpine say

The OpenSSH 10.6p2 release notes speak of fixing a password authentication bypass exploitable through sshd that “affects some Linux systems when built and run with PAM support disabled”. The project itself considers that the root cause lies outside sshd, and describes the fix as a critical security measure for Linux systems with the musl library and PAM disabled.

Alpine's advisory, from the same date, spells out the mechanism: musl's crypt() function returns the text * as an error indicator when the key exceeds 256 bytes. An attacker who sends a very long password (257 to 1,024 bytes) can end up authenticating without knowing the password, as long as two conditions are met: there is an account whose password field is * (an account with no login password) and there is at least one other account whose password is hashed with a $5$ or $6$ type hash. According to Alpine, the attack always works and requires no retries.

These technical details help you understand the risk; you don't need to memorize them. What matters is the consequence: in specific configurations, the password stops protecting access.

Who is affected

Alpine Linux with the openssh-server package, which is built without PAM, and also with openssh-server-pam if it has UsePAM no. With openssh-server-pam and UsePAM yes there is no problem.
All the Alpine versions reviewed: 3.21 to 3.24 and edge, plus the older ones without regular updates (3.16 to 3.20).
Alpine cloud images (tiny-cloud) from 3.18.11 up to 3.24.3 (formats such as qcow2, VHD or AMI), if the machine has any password with a $6$ hash.
Not affected: anyone using Docker containers in which sshd is not running. If you have a container with an SSH server inside, treat it like any other server.

Alpine is common in containers and lightweight virtual machines, and less so on general-purpose servers. If your company has a VPS, its own server or a network device, the useful question is simple: which operating system does it run and is the SSH port open to the internet? If you don't know, ask whoever administers it.

Fixed versions

OpenSSH fixes the flaw in 10.6p2. In Alpine, the fixed packages per branch are as follows:

edge: 10.6_p2-r0
3.24: 10.3_p1-r2
3.23: 10.2_p1-r1
3.22: 10.0_p1-r11
3.21: 9.9_p2-r1

Alpine also published fixed packages for the older branches (3.16 to 3.20) and new cloud images from versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Check Alpine's original advisory before acting, because it is the source that may be updated. Restart the SSH service after updating: according to Alpine, updating the package does not restart an sshd that was already running, and until it is restarted the vulnerable version keeps running (on Alpine, rc-service sshd restart).

Is it being exploited?

Neither OpenSSH nor Alpine report observed attacks. Alpine also noted that, when it wrote its advisory, no CVE identifier had been assigned yet. If you see other data in media or vulnerability dashboards (a CVE number, a score or references to attacks), check it against the official OpenSSH and Alpine advisories before taking it as settled. It is worth treating it as urgent anyway: according to the advisory itself, the attack is simple and reliable.

What to do today: checklist

Identify your servers with reachable SSH and their operating system (cat /etc/os-release). If they run Alpine, follow the steps below.
Update OpenSSH to the fixed package for your branch and restart sshd.
If you can't update right now, turn off password login: set PasswordAuthentication no in the sshd configuration and restart the service. According to Alpine, either measure (patching or disabling passwords) closes the gap. Before doing it, make sure you have key-based access or another way in, so you don't lock yourself out.
Review the access logs for “Accepted password for” lines from accounts that shouldn't be able to log in with a password. That is the clue Alpine suggests.
If there are signs of an intrusion, change credentials and keys, isolate the server and talk to your IT provider or call INCIBE (Spain's national cybersecurity institute) on 017.

SSH good practices that reduce these risks

Log in with keys, not passwords. Disable password authentication whenever possible; this flaw is a good reason.
Limit who can connect: a firewall that only allows certain addresses or a VPN, and AllowUsers to restrict accounts. It is part of what we explain in what a firewall is and what a small business needs.
No direct login as administrator (root): use a normal user with elevated permissions.
Tools against mass login attempts such as fail2ban, and alerts when someone unexpected logs in.
An inventory and a maximum patching window for critical flaws (for example, 48 hours).
Tested backups, in case a server has to be rebuilt: 3-2-1 rule.

Quick questions

Does it affect me if I use Ubuntu, Debian or Red Hat?

Alpine's advisory describes a problem with the combination of musl, which Alpine uses, and sshd without PAM. Glibc-based distributions that use PAM don't fit what is described, but the prudent thing is to check your distribution's advisory and the installed OpenSSH version. And if the server is administered with a password, it's a good moment to move to keys.

What if my website is on shared hosting?

Then server administration is the provider's job. You can ask them whether they use Alpine with SSH exposed and when they apply security patches. See also our guide to domain and hosting.

What if I have a NAS or a router with SSH turned on?

Alpine's advisory doesn't mention them, so we can't say they are affected. But many network and storage devices run Linux, and the manufacturer is the one who publishes their patches: ask about the state of SSH and turn it off if you don't use it.

How we can help at Mitza

We inventory servers, review remote access and apply patches and secure SSH configuration. See how we work in our IT maintenance for small businesses or write to us from the contact page.

OpenSSH 10.6p2: the flaw that lets a very long password get through SSH on Alpine Linux