If you use sshd on Alpine Linux, update openssh and restart sshd: on affected systems, anyone who reaches the SSH port can log in without the password, on a single attempt. Alpine released fixed packages for edge and nine stable branches on November 5, 2026, the same day OpenSSH released version 10.6p2.
At the time of publication, no CVE identifier had been assigned, and neither Alpine nor OpenSSH had indicated a fixed version of musl. Scanners that rely on CVE may not detect it yet.
Am I affected by the OpenSSH vulnerability on Alpine?
You are only affected if all four conditions are met at once:
sshdcomes from theopenssh-serverpackage (compiled without PAM), or fromopenssh-server-pamwithUsePAM no.PasswordAuthenticationis enabled, which is OpenSSH’s default value.- At least one account has
*in the password field. It’s more common than it seems: Alpine has distributedrootasroot:*since approximately 3.16, and this also counts for users who only log in with keys, users from directory services with no shadow entry, and thealpineuser from tiny-cloud images. - At least one other account has a password hash in the format
$5$or$6$.
Affected versions are edge and 3.16 through 3.24.
| Situation | Affected? |
|---|---|
Container that doesn’t run sshd |
No |
PasswordAuthentication no |
No |
openssh-server-pam with UsePAM yes |
No |
Locked accounts (! in the password field) |
No |
No hash with $ format anywhere on the system |
No |
Images with cloud-init that set PasswordAuthentication no |
No |
To check the last two conditions, open /etc/shadow: the second field of each line is the password. * means no password, ! means locked account (not affected), and a value starting with $5$ or $6$ is a hash. Since root:* comes by default, in practice the question is whether any user on the server has a real password set.
How to fix the OpenSSH password bypass on Alpine?
With two commands:
apk upgrade -U -a
rc-service sshd restart
The restart is not optional. Updating the package doesn’t replace the daemon already running.
These are the fixed openssh versions by branch:
| Branch | Fixed openssh version |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Version 3.21 reached end of support on November 1, 2026, but Alpine still released fixed packages for all versions back to 3.16.
Does it affect Alpine Linux cloud images?
Yes, and they are the most dangerous case. The official tiny-cloud images from 3.18.11 to 3.24.3 come with an alpine user with password * and passwordless doas. They are safe on first boot, but as soon as any $6$ hash exists on the instance, the bypass works, and passwordless doas turns that access into root.
Images generated from fixed versions (3.21.10, 3.22.8, 3.23.8, and 3.24.4) and later already include the fix. Instances launched from earlier images need the update or the mitigation in the next section, one by one.
What if I can’t update? How to disable password authentication in SSH
Disable password authentication and leave SSH with key-only access. Before you start, confirm that key-based access works and keep your current session open, so an error doesn’t lock you out.
This is Alpine’s warning block:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication
The last command should show passwordauthentication no.
The drop-in file only takes effect from 3.19 onwards, which is when Alpine’s default configuration starts reading /etc/ssh/sshd_config.d/. That’s why the block also edits /etc/ssh/sshd_config directly: it inserts the setting at the beginning and changes any existing PasswordAuthentication yes line to no, including those within Match blocks. The original is saved as sshd_config.bak.
How do I know if someone already got in?
Search /var/log/messages for sshd lines with Accepted password for on accounts that don’t have a password: alpine, root, or your users who only log in with keys. A password login to an account without a password is the signature of this attack.
On exposed machines, also check doas usage, recently created users and files, and all authorized_keys. If you can’t rule out an unauthorized access, treat the machine as compromised.
What is Alpine Linux and what does musl have to do with it?
Alpine Linux is a lightweight distribution widely used as a base image for containers and in cloud instances, and manages its packages with apk. Unlike most distributions, it uses musl as its C library instead of glibc, and that’s what matters here: OpenSSH describes the affected systems as some Linux systems compiled without PAM support, particularly those using musl libc. That’s why this flaw, which in English circulates as “Alpine openssh password authentication bypass”, is an Alpine problem and not an issue with any server running OpenSSH.
Why does a long password get in without the real one?
The bug is in musl, not in sshd’s own logic. Without PAM, sshd verifies a password by passing the attempt through crypt() and comparing the result with the stored field. For an account whose field is too short to contain a salt, like *, sshd borrows the salt from another account, which is why there must be a $5$ or $6$ hash somewhere on the system.
musl’s crypt() returns * as an error indicator when the key exceeds 256 bytes. * is also exactly what gets stored for an account without a password, so the comparison matches and access is granted. The attacker only needs to send a password between 257 and 1024 bytes.
OpenSSH maintainers consider the root cause to be outside sshd, but it can be prevented from within, and that’s what 10.6p2 does. Alpine’s stable branch packages include a patch with the same effect. The flaw was reported by Özgün Kültekin of Wakefield. The 10.6p2 release notes also indicate that OpenSSH will publish versions more frequently going forward, because AI-assisted reports are uncovering flaws that others find independently.
What about you? What’s the first thing you check when a security notice without a CVE comes out?
- Key-only (
PasswordAuthentication no) - Still with password
- I don’t use sshd on Alpine
- I prefer another option (tell us which)
Comment below or, if you received this article by email, reply directly to the email: your response will be published here.
Related: axios Compromised on npm: What Every JS Dev Needs to Verify Now