8 min read - OpenSSH on Alpine: Prove Exposure, Then Prove the Restart

OpenSSH released Portable OpenSSH 10.6p2 on 5 November 2026 with a critical workaround for a password-authentication bypass. The upstream notice limits the issue to some Linux systems using musl libc with PAM support disabled. The same day, CERT-FR warned that the bypass is trivial when the required conditions are met.

These first notices invite two triage mistakes. One team may search only for the upstream string OpenSSH 10.6p1, although the affected range is OpenSSH before 10.6p2 on those builds and Alpine's fixes for older branches keep their own version numbers. Another may declare every Alpine container compromised, even though a container that does not run sshd is not affected.

Ask a narrower question instead: which reachable SSH services combined the affected runtime, authentication path and account state, and which of those services now run a fixed daemon? Answer it with evidence from the running system, not an image label or a package-install receipt.

The exposure condition is a chain

The OpenSSH 10.6p2 release note describes a bypass through sshd on some Linux builds running without PAM. Alpine's security advisory documents the full conjunction for its distribution:

• sshd runs on musl, using Alpine's non-PAM server package or a PAM build with UsePAM no;
• effective configuration permits password authentication;
• an account has * in its password field (Alpine's examples include key-only users, directory-service users and root, which is reachable only if PermitRootLogin yes is set);
• at least one local account has a $5$ or $6$ password hash; and
• an attacker can reach the SSH service and knows or guesses the star-account name.

Under those conditions, a password between 257 and 1024 bytes (Alpine's figure; other sources state slightly different bounds) can make the failed crypt() result match the * field. Alpine says one connection is enough. Alpine's advisory was written before a CVE identifier existed. MITRE published CVE-2026-123158 later on 5 November, and CERT-FR added it on 6 November. Because the CVE record lists the upstream range and Alpine's fixed packages keep older version numbers, check the distribution package version rather than relying on CVE matches alone.

Do not simplify the chain to “Alpine is vulnerable.” Alpine explicitly excludes systems with PasswordAuthentication no, systems using PAM with UsePAM yes, locked accounts whose field starts with !, and containers that do not run sshd. Glibc systems and OpenBSD are also outside the specific condition described by the researcher's technical account. Other musl-based products need their own vendor or build evidence; an Alpine package table does not prove their status.

Inventory the service that is running

Start with listening SSH endpoints, including public cloud instances, gateways, appliances, build machines and old recovery hosts. A software bill of materials can help locate candidates, but the decision record needs the deployed state for each endpoint.

Record the effective values that sshd applies. sshd_config may include drop-in files, and a Match block can change an option for a user, address or group. Use sshd -T with the relevant connection context where needed, and keep the output with the response ticket. A single line found by text search is weaker evidence.

Separate base-image use from SSH-server use. Alpine notes that Docker and other containers without sshd are not affected. If a team finds the Alpine package in an application image, ask whether the daemon exists, starts and has a reachable port before opening an incident. Check the other direction too: a small VM created outside the usual infrastructure pipeline can run sshd without appearing in any image inventory.

Close the path and verify the running process

For Alpine, the publisher's first instruction is to update openssh and restart sshd. The restart is a separate control: Alpine warns that upgrading the package does not replace the active daemon. CERT-FR's 6 November update states that any fix or configuration change must be followed by an sshd restart. Supported stable branches carry backported fixes, so a host can be fixed without reporting the upstream version 10.6p2.

Record the distribution branch, previous package, fixed package identified by the publisher, upgrade result, service restart time and new process start time. Then open a fresh SSH session through the expected key-based path. Keep the original session available until the new path works, because an emergency configuration change can lock out the operator who must finish it.

If the package cannot be updated at once, both Alpine and CERT-FR recommend disabling password authentication; failing that, CERT-FR advises disabling the service. Test key access first, apply the setting, validate the configuration, restart the daemon and confirm the effective value. A changed file without a restart leaves the old process in charge.

Do not use account edits as the only emergency measure. The vulnerable condition can cover root, key-only users and directory-service users, and local account state may change later. Closing password authentication or stopping the reachable service acts on the entry path rather than today's list of accounts.

Decide whether exposure became an incident

Alpine and the researcher quoted in the CERT-FR alert recommend checking successful password logins for accounts whose /etc/shadow field is *; on Alpine, look for sshd lines reading Accepted password for in /var/log/messages. Alpine also suggests reviewing doas use, newly created users, files and authorised keys. Preserve local SSH logs and any remote authentication, firewall or cloud-flow records before rotation or rebuild work removes context.

Build the exposure interval from the first time all conditions were present until the fixed daemon started. An old vulnerable package does not establish a full interval by itself. The service may have been unreachable, password authentication may have been off, or the required account state may have appeared only after provisioning.

A matching “Accepted password” event for a star account is strong evidence of an unauthorised path and should enter the organisation's incident process. Missing logs do not prove absence. Retention may be short, the endpoint may log elsewhere, or an attacker may have altered the machine. Label that state “exposed, outcome unknown” and let the incident owner decide on isolation, credential work and rebuild.

Alpine documents a separate cloud-image case, which we would check first. Official tiny-cloud images from 3.18.11 through 3.24.3 include an alpine user with a * field and passwordless doas; the image becomes exploitable when another qualifying password hash exists. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Check running instances individually, since rebuilding an image does not update a VM that already exists.

Make the closure record small enough to finish

Use four states rather than a long narrative in the incident tracker:

This record also exposes a supply-chain problem. “We use Alpine” is not enough detail to determine authentication behaviour. Runtime libc, compile choices, PAM state, daemon configuration and account provisioning all took part. Add those properties to golden-image tests for systems that intentionally run SSH, and assert that password authentication remains off where the design expects key-only access.

Our guide to rebuilding monitoring trust after an authentication bypass explains how to treat evidence from a system that may have been altered. The Exceev cybersecurity and engineering approach can help teams connect an urgent fix to image policy, deployment checks and operational ownership.

Sources and limitations

We opened and reviewed every source below on 6 November 2026.

• The Portable OpenSSH 10.6p2 release note is the upstream statement on the workaround, affected runtime condition and release date.
• The Alpine Linux security advisory provides the distribution-specific conditions, fixed package branches, restart requirement, cloud-image scope and investigation guidance.
• CERT-FR alert CERTFR-2026-ALE-015 summarises the risk, affected upstream versions and workaround for French readers, based on the OpenSSH and Alpine bulletins. It relays the researcher's log check, and its 6 November update adds the CVE identifier and a mandatory sshd restart.
• The CVE-2026-123158 record, published by MITRE on 5 November, gives the identifier and the affected range: OpenSSH before 10.6p2 on Linux when musl libc is used without PAM.
• The researcher's disclosure explains the crypt() failure, password-length condition, discovery method and affected account pattern. We use it for technical context, while vendor and CERT instructions control remediation.

We did not inspect a reader's infrastructure, reproduce the bypass or determine that any organisation was compromised. Package versions, advisories and assigned identifiers may change after review. Commands and log locations differ by distribution and service configuration. This article is an operational decision aid, not a substitute for vendor support, incident response or forensic advice.