Any long enough password unlocks some OpenSSH servers on Alpine Linux

One failed attempt, then a password of more than 256 characters (and fewer than 1,024), no matter what it contains. On some Linux servers, that is enough to open a remote session on an account that has no password. The OpenSSH project, the most widely used secure remote login (SSH) software, fixed this flaw on November 5 in version 10.6p2, the release for Linux and other systems.

The same day, CERT-FR, the French government's monitoring and alert center attached to ANSSI (France's national cybersecurity agency), published an alert (CERTFR-2026-ALE-015). It covers Linux systems that use the musl C library and whose SSH server runs without PAM, the usual Linux authentication mechanism. “When the conditions are met, this vulnerability is trivial to exploit,” CERT-FR warns, listing OpenSSH versions prior to 10.6p2 as vulnerable. An identifier was assigned the same day, CVE-2026-123158, and proofs of concept are public. Neither CERT-FR nor the vendor reported any exploitation at that stage.

Three harmless-looking choices made between 2012 and 2016

The flaw was discovered by Özgün Kültekin of the company Wakefield, who details it on a site called “sshole.” It results from the combination of three technical choices. In 2012, musl changed its crypt() function, which computes a password hash: on failure, it now returns the * character instead of an empty value. That same year, musl capped passwords processed by its SHA-512 algorithm at 256 bytes. Beyond that, the computation fails, and therefore returns *.

In 2016, OpenSSH in turn changed its code so as to no longer reveal which accounts exist: for an unknown user or an account without a password, it borrows the “salt,” a random value used to compute the hash, from another account. Yet on Linux, an account without a password, such as an account reserved for SSH keys, can precisely hold a * in the /etc/shadow file. With a password that is too long, the computed hash is *, exactly like the stored value, and the login is accepted. OpenSSH considers that the root cause lies outside its server, but that it can avoid it on its side. It describes its change as a “critical security workaround.”

Who is really exposed?

The conditions are numerous, but they often match default settings. According to the researcher, all of the following must be present:

• a system built on musl: Alpine Linux, Buildroot, Yocto, or a Docker image derived from Alpine that runs an OpenSSH server. OpenWrt, whose default SSH server is Dropbear, is affected only if OpenSSH was installed on it;
• an SSH server without PAM, which is the default for Alpine's openssh-server package, or any configuration with UsePAM no;
• password authentication enabled, which is the default setting;
• an account without a password, marked with a * (a user who logs in only by key, an LDAP account, or the root account on Alpine), and at least one other account with a real password.

The researcher points to a case that could be serious: according to them, Alpine's official images for AWS and Azure create an alpine user who can become administrator without a password, so a fraudulent login would amount to root access. Also according to the researcher, distributions based on the glibc library (Debian, Ubuntu, Red Hat…), systems that use PAM, the Dropbear server and OpenBSD are not affected.

What to do right now

No hacking tool is needed: text that is too long, pasted into the password prompt after a first failed attempt, could be enough. The countermeasures are simple.

• Update OpenSSH to version 10.6p2, or install the patched version provided by your distribution. On Alpine, the openssh-server package 10.6_p2-r0 has been available since November 5 on the “edge” development branch. Alpine also released patched versions for its stable branches, from 3.16 to 3.24, on November 5 (for example 10.3_p1-r2 in 3.24); then restart sshd, which the update does not do.
• In the meantime, disable password authentication: add PasswordAuthentication no to the SSH server configuration, then restart the service. This is the solution CERT-FR favors; failing that, it advises shutting down the SSH service.
• Look for traces: CERT-FR relays the researcher's recommendation to search authentication logs for successful logins to accounts whose password is disabled (* in /etc/shadow). The researcher also publishes a checking tool on GitHub.
• Take inventory of embedded devices and containers built on musl: these are often the systems that get updated the least.

One question remains open: has anyone already walked through this door? “As far as we know, nobody had noticed it,” writes Özgün Kültekin, who traces the problem back to 2016. To be sure, you will have to review your servers' login logs.

Update of November 12, 2026

The OpenSSH flaw that lets an overly long password open accounts supposed to refuse any password login on Linux systems built on the musl library, such as Alpine (CVE-2026-123158, nicknamed “SSHole”), is now being exploited. On November 9, the US cybersecurity agency CISA added it to its catalog of actively exploited vulnerabilities. US federal civilian agencies have until this Thursday, November 12, to patch.

According to the SANS Internet Storm Center, its honeypots, fake servers designed to attract attacks, received a first exploitation attempt as early as November 5, with a password made up solely of the letter “A.” According to BleepingComputer, the company GreyNoise, which monitors malicious traffic on the Internet, observed a first successful intrusion on November 7. As of November 9, it had recorded 16 successful attacks on the networks it monitors, carried out from six IP addresses; its public tracker lists 40, from ten IP addresses, as of November 12. The attackers tried to read password hashes and root SSH keys, and to modify the list of authorized keys. One of them gained administrator (“root”) privileges and installed TAC Agent, a remote control program written in Python. GreyNoise states that these attacks are not representative of all activity related to the flaw.

The guidance does not change: install OpenSSH 10.6p2 or your distribution's patched package, or failing that, disable password authentication. On a server that has remained exposed, BleepingComputer also advises looking for unexpected password logins on accounts whose field in the /etc/shadow file is “*,” SSH keys added without authorization, and TAC Agent startup files or services.