OpenSSH: a password on one account can expose another

An Alpine SSH host can become exposed after a local account changes, even if its package and firewall configuration stay the same. On a susceptible host, adding a supported password hash for one user can enable a bypass against a different account that normally uses a key.

Why the account mix matters

Known exploitation. CISA’s 9 November KEV catalogue update records the addition of CVE-2026-123158. Ireland’s NCSC advisory reports a CVSS score of 8.1. Use CISA’s entry for current KEV status: the NCSC PDF records a different catalogue status, and the severity score does not establish that a specific host is exposed.

Exposure conditions. The OpenSSH 10.6p2 release notes describe the bypass on some Linux systems using musl with PAM disabled. The Alpine Linux advisory documents the specific combination: a reachable, unpatched SSH listener using the affected authentication path, password login permitted for the target, a target password field marked with *, and a SHA-256 or SHA-512 crypt hash on another local account.

Alpine’s mechanism analysis explains why OpenSSH can borrow a salt from another account on the affected path. An overly long input causes musl’s crypt() to return * as an error marker. The same character marks an unset password on the target, so the comparison can accept the login. Alpine illustrates the dependency in affected tiny-cloud images: setting a console password can introduce the missing hash and change exposure without a package or network change. This does not apply to a container without sshd or to Alpine’s PAM package while PAM is enabled. The upstream patch shows the added guard against comparing an invalidly short stored password hash.

Make the decision from the running service

Evaluate the listener, source reachability, effective SSH policy and account classes together. Record whether the target marker and another account’s supported hash are present without exporting hash values. Patch for the distribution branch, including vendor backports. Alpine’s fixed package table lists 10.3_p1-r2 for Alpine 3.24. If the update must wait, the advisory documents disabling password authentication and restarting as a temporary mitigation.

CUP operational recommendation. If SSH supports industrial maintenance, agree on an alternate access route with Operations and verify key access before changing the service. After restart, confirm the corrected process owns the listener, the effective policy is as intended and a fresh authorised key login succeeds. An ordinary rejected password can verify expected behaviour for that attempt; it cannot prove the bypass is fixed. Use isolated test systems for exploit-specific validation.

Assess access during the exposure window

Preserve available SSH and host logs. Alpine’s investigation guidance flags Accepted password for entries for accounts with no password set. CUP recommends checking the account state at the time of the event and correlating it with account changes, new keys or privilege use. Document the period covered and escalate material evidence gaps to the incident owner. If a jump host serves OT, check its permitted downstream routes and privileges separately. KEV confirms exploitation of the vulnerability; it does not establish compromise of a specific host or impact on industrial control.

Infographic: exposure, remediation and evidence

Read the infographic as text

What is confirmed: CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on 9 November 2026. That does not establish compromise of an individual host or access to OT.

1. How the check fails

On the affected path, sshd checks a login for a user with no password set. When an overly long input makes musl’s crypt() return * as an error marker, that value can match the target account’s stored * field and cause the password check to succeed.

2. When this Alpine scenario applies

1. An attacker can reach a running SSH listener.
2. The active daemon is unpatched, uses musl and does not use PAM.
3. The effective policy permits password login for the account and connection.
4. The target account has * in its password field, and a different local account has a $5$ or $6$ password hash.

Treat all four conditions as exposure. A ruled-out condition excludes this documented path. If none is ruled out and one remains unknown, verify before closing.

3. Collect two sets of evidence

Current service: Apply the distribution branch fix and restart. If patching must wait, Alpine advises disabling password authentication and restarting. Confirm the active build and effective policy, and verify a fresh authorised key login.

Prior access: Preserve SSH and host logs. Check for password logins to key-only accounts, new keys and privilege changes. Record the period covered and any gaps; missing logs cannot rule out access.

Illustrative OT case: A package update can leave the old sshd listening on a maintenance jump host. Agree on fallback access with Operations before the restart and assess permitted routes into OT separately.

Related CUP analysis. PHP2Shell explains how to verify a corrected running service. BeyondTrust brokered access examines how privileged maintenance access changes an investigation. Those cases do not establish the exposure of an SSH host.

Next review event. Revisit this analysis if OpenSSH or Alpine changes the documented exposure conditions or if new evidence changes the incident response guidance.