News

OpenSSH accepts oversized passwords on Alpine

Louis Stowasser
Louis Stowasser
Monday 9 November 2026

CVE-2026-123158 is a password-authentication bypass in sshd, OpenSSH’s server daemon for remote shell access. It is not a broad “every SSH server is open” bug: it targets Linux systems using musl libc without PAM, the Pluggable Authentication Modules framework commonly used to hand login checks to the operating system. Alpine Linux is the clearest mainstream example, though the same conditions may turn up in custom lightweight images and appliances.

OpenSSH is the remote-access suite run on servers, administrative hosts, storage gear and network or embedded devices; its SSH daemon is often an exceptionally valuable ingress point. Alpine is common in small server builds and container images, but an Alpine container that does not actually run sshd is not exposed. Normal Linux/glibc deployments and systems using PAM for password authentication are not vulnerable, as the maintainer said in announcing the urgent release.

A failed hash becomes a password match

The bypass stems from how an affected sshd interprets the result of crypt(), the password-hashing function. With musl, an overlong supplied password can make that function return *. If a target account’s stored password field is also *, the old comparison treats the two strings as a successful password check.

The upstream patch adds one small but important guard: a stored value must be at least four characters before it can be accepted as a password hash.

-\treturn encrypted_password != NULL &&
+\tret = encrypted_password != NULL &&
+\t    strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
 \t    strcmp(encrypted_password, pw_password) == 0;
+\tfreezero(pw_password, strlen(pw_password));
+\treturn ret;

For exploitation, an attacker needs network access to the SSH port, password authentication enabled, the affected non-PAM path, a qualifying account with * in its password field, and another local account carrying a $5$ or $6$ hash. Under those conditions, Alpine says a 257–1024-byte password can authenticate without knowing the real password; this differs slightly from CVE wording that says 256–1024 characters. The practical takeaway is to test and hunt for passwords longer than 256 bytes, not to rely on the boundary wording.

Public reproducers shorten the response window

Public lab and self-contained reproduction material is available, so defenders should treat this as reproducible rather than theoretical. Exploitation attempts against Internet-facing systems have been observed; one company also reported a successful root login on its deliberately vulnerable Alpine honeypot. That is not confirmation of a production compromise: no named production victim, attributed campaign or successful real-world intrusion could be confirmed from the available reporting. The CVE was not in CISA’s Known Exploited Vulnerabilities catalogue as of November 9, 2026.

Patch the daemon, then restart it

Portable OpenSSH 10.6p2, released November 5, 2026, contains the workaround; OpenSSH describes it as a security workaround for this musl/PAM-disabled case. Alpine has backported fixes across supported branches, so compare the complete distro package revision rather than upstream version alone. Its advisory confirms affected releases from 3.16 through 3.24 and edge, and stresses that installing the update is insufficient until the running sshd is restarted.

If an update cannot happen immediately, set PasswordAuthentication no and restart sshd; that removes the vulnerable login route, though it requires working key-based access. Inventory Internet-facing Alpine hosts, custom musl images, and appliances first, then verify PAM use and account password fields rather than assuming package presence means exposure. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs; for this flaw, the decisive extra step is mapping the runtime authentication configuration.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203