OpenSSH Bug Lets Any Long Password Into Alpine

If you run an Alpine Linux server, an OpenWrt router with OpenSSH, or a Docker image built on Alpine that exposes SSH, stop and check it today. OpenSSH shipped an emergency release, 10.6p2, on November 5 to block a password bypass that has been sitting in musl-based systems since 2016. On an affected box, an account that was never supposed to accept a password will accept any password longer than 256 bytes.

What happened

Security researcher Özgün Kültekin of Wakefield published the bug (he calls it “*sshole”) on his disclosure page, and OpenSSH pushed the fix the same day. The OpenSSH 10.6p2 release notes describe it as a password authentication bypass in sshd affecting some Linux systems built and run without PAM. Alpine’s security advisory says it takes one connection, works every time and needs no retries. musl maintainer Rich Felker posted his own advisory telling anyone who can’t upgrade to switch off password logins. No CVE had been assigned when the advisories went out. BleepingComputer and The Hacker News on X flagged it within hours.

The mechanics are almost funny. Key-only accounts usually have a single * in /etc/shadow. Since a 2016 timing fix, sshd still hashes the attempt for such accounts, borrowing another user’s salt. musl’s crypt() gives up on passwords over 256 bytes and returns… *. sshd compares * to *, sees a match, and lets you in.

Who is actually exposed

All of these have to be true:

• sshd runs on musl (Alpine, OpenWrt, Buildroot, Yocto and many slim containers).
• PAM is off. Alpine’s standard openssh-server package is built without it, so this is the default there.
• PasswordAuthentication is still yes (OpenSSH’s default).
• One account has * as its password field, and another account has a real password hash.

Debian, Ubuntu, Fedora and other glibc distros aren’t affected, and neither are setups going through PAM or Dropbear. The nasty case is Alpine’s official AWS and Azure images: the default alpine user has passwordless doas, so a login there means root.

What to do

• Update and restart. On Alpine run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package alone leaves the old daemon running. Alpine backported fixed packages to every branch back to 3.16 (for example 3.24 gets 10.3_p1-r2, 3.23 gets 10.2_p1-r1). Check with apk info -v | grep openssh.
• Can’t update yet? Make sure your SSH key works, set PasswordAuthentication no in sshd_config and restart sshd. That alone closes the hole.
• Look for past abuse. On Alpine, grep "Accepted password" /var/log/messages. A password login for an account whose shadow entry is * is a red flag. Rebuild that machine rather than trusting it.
• Containers: rebuild images on fresh Alpine bases instead of patching running containers, and question why a container runs sshd at all.

My take

I don’t think most home users need to panic. Your laptop and your Ubuntu VPS are fine. The people I worry about are the ones who spun up a tiny Alpine VM on a cloud free tier, or flashed OpenWrt on a router and turned on OpenSSH for convenience, then never touched it again. That’s a lot of hobbyist and small-business gear, including plenty of cheap VPS boxes rented by students and freelancers in India who picked Alpine because it fits in 512 MB.

The bigger lesson is boring but real: if you use keys, turn password logins off everywhere. That one line in sshd_config would have made this bug irrelevant, and it would have helped with the Tailscale SSH flaws we covered last month as well. It’s also the third Linux privilege story on this blog in a week, after the APT CVE-2026-109518 fix and OpenAI’s 948 root escalations. Notably, Kültekin says he found this one by having AI agents run about 17,600 odd login attempts. Expect more decade-old bugs to fall out of these AI-driven test runs, and patch accordingly.