What OpenSSH and Alpine say, and what they do not say
OpenSSH 10.6p2 was released on November 5, 2026. Its release notes announce the fix for a password authentication bypass, exploitable through sshd, on some Linux systems built without PAM. The same day, Alpine Linux published an advisory that details the mechanism, the conditions and the fixed packages. The flaw was reported by Özgün Kültekin, of Wakefield.
Two points are worth noting before you act. First, no CVE identifier had been assigned at the date of the Alpine advisory. Some press articles cite one, and we do not repeat it for lack of a primary source. Second, the OpenSSH maintainers consider that the root cause lies outside sshd, and they worked around the problem in sshd. The fix is therefore in the OpenSSH package, not in the C library. As we write, we know of no public report of exploitation, but the technical detail is public: assume that scans will follow.
The five conditions, all required
- A musl C library — this is the case for Alpine, and for other embedded systems that use musl, such as OpenWrt. Debian, Ubuntu, Fedora and AlmaLinux use glibc and are not affected.
sshdwithout PAM — Alpine'sopenssh-serverpackage is built without PAM, and so isopenssh-server-pamwithUsePAM no. WithUsePAM yes, you are not affected.PasswordAuthentication yes— this is the OpenSSH default. If you have set it tono, the flaw cannot be reached.- An account whose password field is
*— a user created without a password for key-based login, a directory user managed by musl-nscd, or thealpineuser of the official cloud images. - At least one other account with a real password (a
$5$or$6$hash) — a single one is enough to expose every account that has no password.
Why a 257-byte password is enough
Without PAM, sshd hashes the submitted password with crypt() and compares the result with the field stored in /etc/shadow. For accounts whose field is too short to hold a salt, sshd borrows the salt of another account, so that response time does not reveal that a username has no password.
On musl, crypt() returns the string * as an error value when the key exceeds 256 bytes. But * is also, in /etc/shadow, the value of an account with no password. The comparison succeeds: the login goes through, and nobody has guessed anything. The Alpine advisory gives the exploitable window: a password of 257 to 1024 bytes. This is neither a cryptographic weakness nor a memory corruption. It is a logic error: an error value taken for a result.
Who is affected, who is not
Scroll the table
| Configuration | Affected? | Why |
|---|---|---|
| Alpine, `openssh-server`, passwords enabled, one account at `*` and one account at `$6$` | Yes | All five conditions are met |
| Alpine, `openssh-server-pam` with `UsePAM yes` | No | Authentication goes through PAM, not through `crypt()` in `sshd` |
| Alpine with `PasswordAuthentication no` | No | No password authentication is attempted |
| Debian, Ubuntu, AlmaLinux, Rocky (glibc) | No | The comparison does not receive the `*` error value |
| Alpine container without `sshd` | No | No SSH service to attack |
| Account locked with `!` instead of `*` | Not for this account | `!` does not match the error value |
| Official Alpine cloud image, no password set | Not at first boot | The advisory says it becomes exploitable as soon as a `$6$` hash appears, for example a password set at the console |
"I am on Debian or Ubuntu: does this affect me?"
No, not for this flaw: it requires musl. The objection is still worth raising, because the useful question for a fleet lies elsewhere: where do you find Alpine without having chosen it? A container image that bundles an sshd for troubleshooting, a network appliance, a router running OpenWrt, an image built with Buildroot or Yocto: all of them may rest on musl, depending on how they were built. On a VPS running Debian or Ubuntu, the exposure comes from an Alpine container with sshd that you run there, not from the host system.
An inventory takes two commands per machine: ls /lib/ld-musl* tells you whether the system uses musl, and ps aux | grep sshd tells you whether an SSH service is running. Do it in your containers too, because an image rebuilt last year may still carry the old package.
Check your exposure, then fix it
Confirm that the system uses musl
Run
ls /lib/ld-musl*orldd --version 2>&1 | head -1. On Alpine, the answer mentions musl. On glibc, there is nothing to do for this flaw.Note the OpenSSH version and the PAM variant
apk info -vv | grep '^openssh'lists the installed packages. Note whetheropenssh-server-pamis present, then checkUsePAMin/etc/ssh/sshd_config.Read the configuration actually applied
sshd -T | grep -i -E 'passwordauthentication|usepam|permitrootlogin'prints the effective values, including those fromMatchblocks and included files. A line read in the file is no substitute for this check.List the accounts at `*` and the accounts with a real password
awk -F: '$2=="*" {print $1}' /etc/shadowgives the accounts without a password;awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowgives those that have a hash. If neither list is empty, conditions 4 and 5 are met.Update the package
apk upgrade -U -ainstalls the fixed version. Alpine has published fixed packages for all its branches, down to 3.16, including those that are no longer supported.Restart the service, otherwise nothing is fixed
rc-service sshd restart. Updating the package does not replace the running daemon: until it is restarted, the old code keeps answering. Keep one session open during the restart and test a second connection before closing it.Check the result
Re-run
apk info -vv | grep '^openssh', thensshd -T | grep -i passwordauthentication. After that, open a key-based connection from another machine to confirm that access works.Rebuild the images
A container image or a VM image cannot be fixed in place: rebuild it from a fixed base, then redeploy it. Record the date of the fix in the environment's file.
Fixed packages by Alpine branch
Scroll the table
| Branch | Fixed openssh package | Branch version |
|---|---|---|
| edge | 10.6_p2-r0 | — |
| 3.24 | 10.3_p1-r2 | 3.24.4 |
| 3.23 | 10.2_p1-r1 | 3.23.8 |
| 3.22 | 10.0_p1-r11 | 3.22.8 |
| 3.21 | 9.9_p2-r1 | 3.21.10 |
| 3.20 and older (down to 3.16) | 9.7_p1-r6 (3.20); 9.0_p1-r6 (3.16) | Unsupported branches |
Look for traces before concluding that all is well
A fix removes the flaw; it does not erase what an attacker did before. The Alpine advisory recommends searching /var/log/messages for Accepted password for lines that concern accounts that are not supposed to have a password: alpine, root or a user reserved for key-based logins. Such a line is a strong indication, since these accounts should never log in with a password.
For the accounts that appear, then check the use of doas, recently created users, modified files and the contents of every authorized_keys. The advisory leaves no doubt about what to do: if you cannot rule out a login, treat the machine as compromised, rebuild it and renew the secrets it held. On the official cloud images, the risk is higher: the alpine user has passwordless doas there, which allows becoming root once inside.
Cannot update right away? Disable password authentication, after checking that a key-based connection works and keeping your current session open. Alpine suggests a file in /etc/ssh/sshd_config.d/ containing PasswordAuthentication no (the directory is read by default since 3.19), provided that no PasswordAuthentication yes line remains in a Match block. Finish with sshd -t, a restart, then sshd -T | grep -i passwordauthentication, which must print passwordauthentication no. To undo it, delete that file.
Troubleshooting: what you may see when applying the fix
The messages below are OpenSSH messages. They appear on the client side in the terminal, and on the server side in the service log.
Messages and remedies
Permission denied (publickey).— after turning passwords off, your key is not accepted. Keep the session open, check the account's~/.ssh/authorized_keys(permissions600, directory700), then re-readsshd -T | grep -i pubkeyauthentication. Do not close the original session until you have a second connection that works.Bad configuration optionfollowed by a name, with a line number from/etc/ssh/sshd_config— a typo in the file or in the included file.sshd -treports it before the restart: never restart without this check.sshd: no hostkeys available -- exiting.— the host keys are missing, for example in an image where they were not generated. Generate them withssh-keygen -A, then restart the service.- The daemon still answers with the old version — you updated the package without restarting. Run
rc-service sshd restart, then re-read the version announced at connection.
What this flaw says about your fleet
It does not come from a spectacular bad practice: one account without a password, another with a password, a default value. Each of these choices is common, and it is their combination on an uncommon system that creates the exposure. The lasting answer is the same as before the flaw: on any server reachable from the Internet, authenticate with keys, disable passwords, and know which images and which containers carry an sshd.
If you have already hardened your access, this alert is settled in ten minutes per machine. If not, it is an opportunity to do so: the full procedure is described in our first SSH access guide, and updating OpenSSH 10.6 without locking yourself out is covered in the article devoted to that version. A ServOrbit VPS gives you root access and the choice of system, which leaves you in control of these settings.
