Alpine OpenSSH Password Bypass: Is Your Server Affected?

The Alpine OpenSSH password bypass does not affect every Alpine server or container. Check whether an SSH daemon runs, whether it allows password authentication, whether PAM is active, and whether the account conditions in Alpine’s advisory apply. Using SSH keys alone does not establish safety: password authentication can remain enabled alongside them. Alpine’s advisory.

OpenSSH released portable 10.6p2 on November 5, 2026, with a critical workaround for Linux systems using musl without PAM. Upstream says the root cause lies outside sshd. CVE-2026-123158 is now assigned, although Alpine’s advisory initially said no identifier had been assigned. OpenSSH release notes, published CVE record.

The decision table below combines the vendor’s conditions into an applicability check. It is a reading of the advisory, not a scan of your infrastructure or a reproduction of the vulnerability. Package details are a November 6 snapshot; use the linked advisory for subsequent changes.

Which Alpine SSH servers are affected?

The affected configuration requires several conditions to hold together. An Alpine label, an installed OpenSSH package or an older version number cannot establish all of them.

Alpine identifies a non-PAM authentication path with password logins enabled, an eligible account whose password field contains *, and another local account with a $5$ or $6$ password hash. Its default openssh-server package uses the non-PAM path. Installing openssh-server-pam does not remove that condition if UsePAM remains no. Vendor prerequisites.

Use the table for this specific bypass. “Unaffected” assumes you have established the active configuration for the relevant account and connection.

These classifications synthesize Alpine’s advisory. They do not describe the system’s overall security or establish whether a past compromise occurred.

The account distinction matters. Alpine distinguishes a * placeholder from a ! lock; do not treat every disabled-looking password field as equivalent. Check account prerequisites through your authorized administration process without copying password hashes into tickets or chat. Do not edit account password fields as an improvised workaround.

Check root policy carefully, too. A setting that blocks direct root password login does not answer whether another eligible account is exposed. Likewise, a private network changes who can reach a service; it does not change whether its authentication configuration matches the advisory.

Does using SSH keys protect you?

“We use SSH keys” and PasswordAuthentication no are different facts. A successful key login proves that key authentication works. It does not prove the server rejects password authentication for that user or for other users.

Small teams can easily miss that distinction. Everyone may have stopped typing passwords years ago while the daemon still accepts password attempts. Inspect the server setting rather than inferring it from how your team usually connects. Alpine explicitly lists disabled password authentication among the exclusions for this bypass. Alpine’s configuration guidance.

The same reasoning applies to PAM, the authentication framework used by the alternative server package. Confirm both the package and the active UsePAM setting. A package inventory that says “PAM” is incomplete evidence when the service is configured not to use it.

Cloud images need their own check. Alpine’s advisory discusses tiny-cloud and cloud-init separately, so avoid treating all cloud images as one configuration. Identify the image setup and subsequent account changes, then compare them with the vendor’s cloud-image notes. A base image name cannot tell you what an administrator changed after boot.

Which Alpine packages contain the fix?

Alpine backported the correction to older package branches. Compare your branch and complete package revision with the vendor table, rather than requiring every machine to display upstream 10.6p2.

Selected fixed packages, checked November 6:

Source: Alpine’s fixed-package table. This is an excerpt, not a complete support matrix. Consult the advisory for other branches. A backport does not renew support for an end-of-life release.

For an affected service, follow Alpine’s package upgrade instructions and restart sshd. On an OpenRC-managed Alpine service, the advisory specifies:

rc-service sshd restart

Use your actual supervisor’s procedure when a container or another service manager controls the daemon. If you cannot immediately upgrade, Alpine documents disabling password authentication and restarting the service as a mitigation. Follow the vendor’s mitigation instructions rather than copying a configuration rewrite into an unfamiliar setup.

Before changing remote access, preserve a working key session and access to your recovery console. Arrange a separate legitimate login check so a configuration mistake does not strand you outside the server.

What should you check after updating?

Check the configuration in the same context as the service, then confirm the service change took effect. Configuration diagnostics and a fresh login answer different questions.

The official manual documents sshd -t for configuration and key checks, and sshd -T for printing effective parsed configuration. Supply -C when evaluating connection-dependent Match rules. For example:

sshd -t
sshd -T -C user=example,addr=192.0.2.10,host=example.test

The user, address and hostname here are illustrative values. Replace them with a relevant connection context and inspect other contexts where rules differ. Match the running service’s executable, configuration file and startup options. Official sshd manual.

These commands start a new process. They do not interrogate settings already held by the running daemon. Successful output cannot establish that the intended restart completed and the corrected service is running.

After the change, open a separate authorized key session while retaining your existing access. Confirm the intended account still works and the service has the expected authentication settings. Do not attempt the bypass against production to obtain a reassuring result. A successful fresh login is an access check, not evidence that password authentication is disabled or that no earlier compromise occurred.

Keep unknown configurations assigned

Leave an unresolved prerequisite visible. “Unknown PAM setting” or “restart unconfirmed” tells the next engineer what remains to establish; a broad “Alpine checked” label hides that work.

If an affected service arrives as a vulnerability report, Kit Security can keep its assignee, assessment, internal discussion and recorded fix verification together. Your operator supplies the host and service evidence; the report workflow does not discover Alpine servers or verify daemon state automatically.

Start with the service your team can inspect now. Establish its authentication path, compare its package with Alpine’s branch-specific fix, and confirm the required service change. Keep the remaining configuration questions assigned until someone can answer them.