CVE-2026-123158: OpenSSH Password Bypass Lets Attackers Log In to Alpine Linux Servers With an Overlong Password

Critical · 2026-11-05 · By H.A

CVE-2026-123158: OpenSSH Password Bypass Lets Attackers Log In to Alpine Linux Servers With an Overlong Password

On Alpine Linux and other musl-based systems running sshd without PAM, any 257–1,024-byte password can unlock accounts marked '*', so patch to the fixed openssh package, restart sshd and disable password logins now.

Overview

A password authentication bypass in OpenSSH's server, tracked as CVE-2026-123158, lets a remote attacker log in to some Alpine Linux systems in a single attempt without knowing the password. The flaw affects Linux systems where sshd is built against the musl C library and runs without PAM. That is exactly how Alpine ships its default openssh-server package.

The OpenSSH project released portable OpenSSH 10.6p2 on 5 November 2026 with a workaround in sshd. Alpine published a security advisory the same day, along with fixed packages for every supported branch and for older branches back to 3.16. Neither the OpenSSH project nor Alpine reported exploitation in the wild at the time of publication. Because the attack is trivial once a vulnerable host is found, defenders should treat this as an emergency patch.

The Vulnerability

According to the official CVE description, sshd lacked a workaround for a password check that misinterprets whether a stored string is meant to be a password hash. On affected configurations, any password between 257 and 1,024 bytes long is accepted for certain accounts.

The OpenSSH developers say they consider the root cause to lie outside sshd itself, in how the underlying system handles the stored password value. The bug is still reachable through sshd, so it can be blocked there, and that is what 10.6p2 does.

Alpine's advisory says a host is exposed only when all of the following are true:

Accounts locked with ! are not affected. Neither are systems using PAM for password authentication, systems on glibc, or non-Linux systems. Alpine notes that root is protected by the default PermitRootLogin prohibit-password, so the realistic target is any other account marked *. Key-only accounts were never meant to accept passwords at all, so this is especially dangerous.

Affected and Fixed Versions

Supported Alpine branches 3.21 to 3.24 and edge are affected, as are the end-of-life branches 3.16 to 3.20. The fixed openssh package versions are:

New Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. Tiny-cloud images from 3.18.11 up to 3.24.3 are affected. Other musl-based distributions that ship OpenSSH without PAM should be checked against their own vendor's guidance.

Timeline

Tradecraft

Exploitation needs only network access to an exposed SSH port and a username of an account whose password field is *. Such accounts are easy to guess: common admin and service account names, cloud image default users, or directory accounts. The attacker then submits an overlong password in the 257 to 1,024 byte range. No brute force or credential theft is needed, and the login succeeds in one attempt.

The most likely abuse is opportunistic mass scanning of internet-facing SSH on Alpine-based virtual machines, cloud instances, appliances and containers that run sshd. Once inside, expect the usual follow-on activity: persistence through authorized_keys, new local users, privilege escalation through doas or sudo, cryptomining, and use of the host for further scanning.

Indicators of Compromise

No attacker infrastructure or malware has been published for this vulnerability. Hunt for behaviour instead (see Detection).

Detection

Check whether a host is exposed:

# package and version
apk info -v 2>/dev/null | grep -E '^openssh-server'

# effective sshd settings
sshd -T | grep -Ei '^(usepam|passwordauthentication) '

# accounts whose password field is exactly "*"
awk -F: '$2=="*" {print $1}' /etc/shadow

# accounts with $5$ / $6$ hashes
awk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

Look for logins that should not exist:

grep 'Accepted password for' /var/log/messages

A password login for any account that has no usable password, or for an account that normally signs in only with keys, is a strong sign of exploitation. Also review recent doas use, newly created users, recently changed files and any edits to authorized_keys. Centralised logging teams should alert on Accepted password events for key-only accounts on Alpine hosts.

Recommended Actions

  1. Patch now: run apk upgrade -U -a, then restart sshd (rc-service sshd restart). Upgrading the package does not restart the running daemon.
  2. If you cannot patch immediately, turn off password logins. Create a drop-in file and restart sshd. Keep your current session open and confirm key login works first:
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication'
  1. Rebuild container images that run sshd on Alpine, and redeploy from the fixed base image.
  2. Lock key-only accounts with ! rather than * where your tooling allows it, and restrict SSH exposure with firewalls or a bastion.
  3. If you find an unexplained password login, treat the host as compromised: isolate it, rotate keys and credentials, and rebuild it.

Analyst Assessment

This is a critical, easy-to-exploit bug with a narrow but common set of conditions. Alpine is the default base for many container images, appliances and small cloud instances, and its stock SSH package has PAM off and password logins on. Many hosts will meet the conditions without their owners realising it. Accounts marked * are usually thought of as "no password", which makes the bypass especially dangerous because it hits the accounts admins consider safest.

Expect scanning to start quickly now that the trigger is public. Disabling password authentication is a reliable mitigation that costs nothing on key-based fleets, and it should be done everywhere regardless of patch status.

REEF SENTINEL