Alpine OpenSSH Password Authentication Bypass Fixed

Alpine Linux has issued a security advisory for a password authentication bypass in its OpenSSH server builds: an attacker who can reach SSH and meet a short list of conditions can log in without knowing any password, in a single connection, Alpine said on 5 November 2026. Portable OpenSSH 10.6p2, released the same day, documents a critical security workaround for Linux systems that use musl libc with PAM disabled. musl maintainer Rich Felker separately advised OpenSSH-plus-musl users to set PasswordAuthentication no and restart sshd if they cannot upgrade immediately.

No CVE identifier had been assigned when Alpine published. The bug was reported by Özgün Kültekin of Wakefield, OpenSSH’s release notes say.

Who is actually exposed

Alpine says you are affected only if all of the following are true. You run the Alpine openssh-server package built without PAM, or openssh-server-pam with UsePAM no (UsePAM yes is not affected). PasswordAuthentication is yes (OpenSSH’s default unless changed). The machine has an account whose password field is * — common for key-only users, for root:* in the base image since about Alpine 3.16, for the alpine user in official tiny-cloud images, and for some directory-service users via musl-nscd. And at least one local account has a $5$ or $6$ password hash. The attacker then sends a very long password (257 to 1024 bytes). Alpine’s wording is that one user with a password is enough to make every account without one reachable under those conditions.

Who is not affected, per Alpine: containers that never run sshd; systems with PasswordAuthentication no; openssh-server-pam with UsePAM yes; locked accounts with ! in the shadow password field; systems with no $-style password hash; and cloud-init images that already write PasswordAuthentication no. Felker’s musl note adds that Dropbear and other non-OpenSSH password logins are not in scope, and that he sees the root cause as erroneous use by the caller rather than a musl bug — while OpenSSH’s notes say they consider the root cause outside sshd but still exploitable via it.

Affected Alpine releases include 3.21 through 3.24 and edge, plus older branches 3.16 to 3.20 that no longer receive regular updates. Fixed point releases named by Alpine are 3.21.10, 3.22.8, 3.23.8 and 3.24.4, with fixed openssh package versions listed back through 3.16.

Patch, then restart — or shut the door

The operational sequence Alpine publishes is deliberate: run apk upgrade -U -a, then restart sshd with rc-service sshd restart. Upgrading the package does not replace a running daemon. If you cannot update yet, disable password logins (PasswordAuthentication no) and restart sshd after confirming SSH key access still works and keeping the current session open until a new login is tested. Alpine publishes drop-in and sed commands for that workaround; the check is sshd -T | grep -i passwordauthentication printing passwordauthentication no.

For UK and EU operators, Alpine sits under a lot of containers, CI runners, edge boxes and appliance images even when the “brand” on the ticket is something else. Inventory who actually runs Alpine openssh-server without PAM, whether PasswordAuthentication was left at the default, and whether any * accounts share a host with a local $5$/$6$ hash. That is a configuration hunt, not a CVE-id hunt — and there is no CVE yet.

Patch debt looks the same whether the product is dead or alive

The pattern will be familiar to readers of today’s other infrastructure posts. Canada’s flag on a Zyxel GS1900 flaw and Rails’ emergency Active Storage / ImageMagick releases are both reminders that the fix only counts when it is installed and the process is recycled. Crédit Mutuel Arkéa’s cyberattack disclosure shows what a live incident looks like when the window has already closed. SonicWall’s decision not to patch two GMS flaws on an end-of-life product is the opposite failure mode: no vendor path left. Alpine still has a path — point releases and backported packages — but only for operators who upgrade and restart.

Treat the Alpine OpenSSH advisory as a same-day ops ticket: upgrade, restart sshd, or turn PasswordAuthentication off. Watch for a CVE assignment and for other musl-based distributions to publish matching notes. Until those arrive, the confirmed facts are the ones Alpine, OpenSSH 10.6p2 and Felker already put on the record.

Sources

• Security advisory: openssh-server password authentication bypass (Alpine Linux, 5 November 2026)
• OpenSSH 10.6p2 release notes (5 November 2026)
• Advisory for OpenSSH+musl users (Rich Felker / musl list, 5 November 2026)

Related stories

• Canada Flags Zyxel GS1900 Vulnerability as Possibly Exploited
• Rails Security Releases Fix Critical Active Storage Flaw
• Crédit Mutuel Arkéa Confirms Cyberattack on Its Own Accounts
• SonicWall Won’t Patch Two GMS Flaws as the Product Is End-of-Life