Alpine Linux patches critical SSH bypass on all four supported branches
Alpine Linux pushed four coordinated point releases out the door in a single day, and one of them closes a serious hole in the SSH server. With the 3.21.10, 3.22.8, 3.23.8 and 3.24.4 drops today, the project fixed a flaw that lets anyone who reaches your SSH port log in without a password. It works on the first try. Every time. No brute-forcing. No luck involved.
The updates span every supported branch at once, which is the normal Alpine pattern but worth repeating given how usable this particular bug is. Alpine kept the announcement terse, as is its habit, with a one-line summary that the releases "include security fixes across core components." It pointed readers to per-branch git logs for the full change lists. Two fixes carry the real weight here.
An unauthenticated login that works first try
The headline is a flaw in the Alpine-packaged OpenSSH server, bad enough that the project wrote both a release note and a full dedicated security advisory. That is not something you see every Tuesday. Per the advisory, the bypass "takes one connection, works every time, and needs no retries," which is a striking way to describe an auth hole because it removes most of the work an attacker would normally do.
No CVE has been assigned yet, so the flaw is being referenced by behavior rather than a tracked ID. Alpine shipped the fix using upstream OpenSSH 10.6p2, which itself landed the same day.
Here is where it gets specific. The advisory is unusually careful about exactly when the bug bites, since the vulnerable setup is not universal. A machine is only at risk if every one of these conditions lines up: the OpenSSH build runs without PAM, PasswordAuthentication is set to yes (the default), at least one account carries a * password field, and at least one local account holds a $5$ or $6$ hash.
That last point is what tends to trip people up. A single account with a scrypt or SHA-256/512 hash is enough to make every no-password account reachable, so it is not about the account you are actually worried about. It is about the account sitting next to it.
The practical upshot is that a lot of default Alpine setups match the vulnerable profile. The root account ships as root:* in the base image, key-only users created with adduser have no password, and the alpine user in the tiny-cloud images sits in the same boat.
You are probably not affected, but it is worth checking. Docker containers that do not run sshd inside them are fine, as are systems with PasswordAuthentication no, locked accounts, and cloud images configured through cloud-init, which writes that flag off. Alpine also tested older releases that no longer get regular updates, and every branch from 3.21 through 3.24 plus edge all contained the same bug.
There is a lifecycle wrinkle worth flagging. Alpine 3.21 hit end-of-support on 2026-11-01, four days before this fix, yet the project still published a patched openssh for it and backed all the way down to 3.16. That is the project's stated habit of backporting security fixes for widely deployed components even after formal support ends.
The technical root cause is a collision between two unrelated projects. When sshd runs without PAM it verifies a password by hashing the attempt with the C library's crypt() function and comparing it to the stored field in /etc/shadow. musl's crypt() returns the literal string * when the input key is longer than 256 bytes, and that same string is exactly what a no-password account stores. Send a password between 257 and 1024 bytes and the two lines meet. OpenSSH 10.6p2 avoids the problem on its side, and Alpine's stable packages carry a backported patch for older OpenSSH versions.
Here is a small aside while we are on the subject of who keeps finding these bugs. The same-day OpenSSH 10.6p2 release notes carried a note that the team had received "a large number of security bug reports, many of which are findings from AI models or made with AI assistance." The SSH people observed that bugs found by AI tools tend to turn up independently anyway, so they are committing to more frequent releases to get fixes out faster instead of batching them for the next planned drop. Fair enough, and it is a telling sign of where the discovery pipeline is heading.
Closing the hole is straightforward with two mutually exclusive paths. The recommended move is to upgrade and then restart the daemon.
apk upgrade -U -a
Then the part people forget:
rc-service sshd restart
Upgrading the package does not restart the running service, so your sshd keeps serving vulnerable code until you issue the restart. That gap gives a lot of administrators false reassurance, which is exactly the wrong thing to hand someone. A follow-up check with sshd -T | grep -i passwordauthentication confirms the running daemon.
If patching is not possible right now, you can disable password authentication instead, but only after confirming key-based login works and keeping your current session open until a fresh login goes through. The advisory offers a drop-in file as well as a sed rewrite that catches PasswordAuthentication yes lines inside Match blocks too. Alpine's default sshd_config reads the drop-in directory from 3.19 onward, so older releases need the sed route.
The other update in this batch is a crash fix in apk-tools, Alpine's package manager. It prevents a crash on malformed data, which is the same family of bugs that has plagued the tarball parser before, things like invalid frees and segmentation faults. Alpine ships two major generations of apk-tools, and this fix lands in 3.0.9 for the 3.23.8 and 3.24.4 branches and in 2.14.13 for 3.21.10 and 3.22.8.
It is less glamorous than the SSH flaw, but apk-tools is foundational, so a crash mid-operation can leave a system inconsistent. The fact that it spans both the apk 2 and apk 3 lines is exactly why it touched all four branches for a different reason than the SSH update. Coordinated multi-branch releases are simply how Alpine works, and today's batch fits neatly into recent history. The previous point releases focused on a broad OpenSSL advisory plus musl, zlib, ca-certificates and PHP fixes. Today's is narrower in the components named but arguably more immediately dangerous, since an unauthenticated remote login is easier to weaponize than most cryptographic flaws.
On any host running sshd, run apk upgrade -U -a, restart sshd, and verify. If patching is not possible today, disable password authentication after confirming key login works. Cloud and tiny-cloud operators should rebuild from images dated 3.21.10 or later where you can, and for running instances, update openssh or audit /etc/shadow for a $6$ hash. If you see Accepted password for on a no-password account in /var/log/messages, treat the machine as compromised.
More details are available in the Alpine announcement and the dedicated openssh advisory, both dated 2026-11-05, or the OpenSSH release notes for the 10.6p2 details.
