OpenSSH Fixes a Critical Login Flaw

If you run an SSH server on Alpine Linux, stop what you're doing and patch. OpenSSH 10.6p2, released on November 5, 2026, fixes a flaw the project itself rates critical: on some Linux servers, an attacker can log in without knowing the password. No brute force, no clever timing trick - one connection, and it works every time.

What actually happened

The bug sits in how sshd, the OpenSSH server, checks passwords on Linux systems built with the musl C library when PAM (Pluggable Authentication Modules) is disabled - which is exactly how Alpine Linux ships its openssh-server package. An attacker who can reach your SSH port and knows the name of an account with no password set (a * in the password field, perfectly normal for key-only accounts) can get in by sending a very long password, between 257 and 1,024 bytes. The only other requirement: at least one other account on the machine has a $5$ or $6$ password hash. One user with a password makes every account without one reachable.

That matters more than it sounds. On Alpine's base images, root has shipped as root:* since around Alpine 3.16, and the official tiny-cloud images create an alpine user with passwordless doas access. Log in as that user and you're one doas command away from root. OpenSSH says it considers the root cause to be outside sshd, but since the bug is exploitable through sshd, the project shipped a workaround there. It was reported by Özgün Kültekin of Wakefield.

Who needs to worry (and who doesn't)

• Affected: Linux systems built on musl libc with PAM disabled - Alpine's openssh-server package, openssh-server-pam with UsePAM no, and potentially OpenWrt (only if you installed OpenSSH yourself; its default Dropbear server is not affected, according to the reporter's write-up), Buildroot and Yocto builds. You also need PasswordAuthentication yes (the default) and the account mix described above.

• Not affected: glibc-based distros (Debian, Ubuntu, Fedora and friends), systems authenticating through PAM, servers running PasswordAuthentication no, accounts locked with ! in /etc/shadow, containers that don't run sshd, and cloud images configured through cloud-init.

Fix it now

Alpine published fixed packages for every release back to 3.16, and the fresh point releases (3.21.10, 3.22.8, 3.23.8 and 3.24.4) already include them. Two commands and you're done:

apk upgrade -U -a
rc-service sshd restart

The restart is not optional: upgrading the package does not replace the running daemon. If you can't update right away, set PasswordAuthentication no in your sshd config and restart - that alone closes the hole (just make sure your key login works first, and keep your current session open). OpenSSH's Damien Miller was blunt about it: "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY." No attacks abusing the flaw have been reported so far, according to The Hacker News.

The bigger story: AI is compressing disclosure timelines

Tucked into the official release notes is a policy shift worth your attention. The OpenSSH team says it now receives a flood of security reports generated or assisted by AI models, and that bugs first flagged by AI tools are often rediscovered independently by other researchers. The team's conclusion: adversaries who don't report bugs are likely able to find them too, so OpenSSH will ship more frequent releases to get fixes into users' hands faster instead of batching them into the next planned release. This emergency 10.6p2 workaround release is that policy in action.

Running Alpine or another musl-based system somewhere? Check your sshd config, update, restart - the Alpine advisory walks through both the patch and the mitigation step by step. And if you want the full picture on the tool itself, our OpenSSH page has you covered.

Cover image: OpenSSH 4.6 in GNOME Terminal on Arch Linux (2007), by Karam.Anthony.K, via Wikimedia Commons (free license).