Alpine's SSH bypass needs a package update and daemon restart

Alpine Linux has released fixes for an SSH password-authentication bypass that can admit an attacker without a valid password. Its November 5 advisory tells administrators to update the package and restart sshd, the SSH server. Updating the files on disk leaves an already-running daemon unchanged.

Evidence status: a vendor-confirmed vulnerability, with repairs published by Alpine and OpenSSH. The reviewed advisories give no confirmed attack campaign or victim count. Alpine credits Özgün Kültekin of Wakefield with reporting the issue.

A key-only account can still accept a password attempt

The exposure requires several conditions together:

• The attacker can reach the server’s SSH port.
• The server uses musl, Alpine’s C library, with PAM disabled. PAM is the authentication framework some Linux services use. Alpine’s ordinary openssh-server qualifies; openssh-server-pam qualifies when configured with UsePAM no.
• PasswordAuthentication yes remains effective for the affected login.
• An otherwise login-eligible account has * as its stored password field.
• At least one local account has a $5$ or $6$ password hash.

That combination can expose an account intended for SSH keys alone. Configuring a key for one user does not disable the server’s password-authentication path. Setting a password for a different local account can complete the conditions.

Alpine traces the bypass to a password-hashing error result that can equal the target account’s stored * marker. The authentication check then accepts that error as a matching password hash. Alpine says no CVE identifier had been assigned when it published the advisory.

Alpine says releases 3.16 through 3.24 and edge are affected under those conditions. Containers that run no SSH server have no exposure through this service. Systems using PasswordAuthentication no, or the PAM-enabled package with UsePAM yes, are outside the advisory’s affected configuration.

The password marker also matters: Alpine distinguishes !-locked accounts from accounts whose field is *. Default root protection matters separately. PermitRootLogin prohibit-password protects root from password login, but another exposed account may have administrative privileges.

Cloud images can become exposed after setup

Alpine specifically identifies official tiny-cloud images from 3.18.11 through 3.24.3. They include an alpine account with the relevant password marker and passwordless doas, a tool for running commands as another user.

The advisory says these images are safe on first boot. Creating a qualifying local password afterward can make the alpine account reachable and permit escalation to root. That includes setting a console password or adding a user with a stored hash through user-data.

Cloud-init images that configure PasswordAuthentication no are a separate case. Check the actual image and effective configuration rather than treating every Alpine cloud instance as identical.

Use the repair for the installed branch

OpenSSH 10.6p2 supplies an upstream workaround for the musl/non-PAM combination. Alpine backported protection into its older package lines. An older upstream version number alone therefore cannot determine whether an Alpine package is repaired.

Alpine lists these fixed openssh packages:

The new Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the repaired package. Existing instances still need updating. Alpine supplied exceptional backports to older branches; that does not restore their normal support lifecycle.

Follow Alpine’s upgrade guidance and restart sshd afterward. Its documented OpenRC restart command is rc-service sshd restart.

If updating must wait, Alpine recommends PasswordAuthentication no followed by a daemon restart. First verify working SSH-key access and keep the current session open while testing a new login. Validate the configuration and account for conditional Match rules. Alpine warns that older releases may ignore the drop-in directory used by newer configurations.

Review unexpected successful logins

Alpine recommends examining /var/log/messages for Accepted password for an account that has no password, including key-only users. Review administrative doas use, newly created accounts, files and authorized keys on previously exposed machines.

If a suspicious login cannot be ruled out, Alpine advises treating the machine as compromised. Closing the authentication path does not undo changes or recall copied credentials. Missing or expired logs cannot establish that no login happened.

What the thread adds

The OpenSSH release discussion exposes two assumptions worth checking against the advisory:

• MPSimmons reports an Alpine installation using ! rather than *. This is an individual observation; Alpine’s advisory confirms that the distinction changes exposure. It cannot establish every image’s default.
• dspillett writes: “We have clients (regulated banks and insurers of various sizes) that send us feeds via SFTP.” The commenter says some request password authentication despite a recommendation to use keys. This is self-reported operational experience, not a prevalence measurement. Check service dependencies before changing authentication, while prioritizing the package repair.

From a 65-comment thread, in HN’s own order.

Caveat: These repairs address the documented musl/non-PAM bypass; neither publication of a patch nor a clean log review proves an exposed machine was never accessed.