A flaw in OpenSSH makes it possible, in certain configurations, to log in to a Linux server without knowing the password, in a single attempt. CERT-FR issued an alert on 5 November (CERTFR-2026-ALE-015), updated on 6 November with the identifier CVE-2026-123158. Alpine Linux systems, a distribution built on musl, are the most affected; the fix requires restarting the SSH service.
A password-free login, under certain conditions
The vulnerability affects OpenSSH versions prior to 10.6p2, but only on Linux systems that use the musl C library and whose SSH daemon runs without PAM, the usual authentication module. According to CERT-FR, an attacker can then open a session by sending two successive passwords, the second being more than 256 and fewer than 1,024 characters long. The government agency describes exploitation as “trivial” when these conditions are met. Its alert does not report any observed attacks.
The Alpine Linux advisory, published the same day, sets out the full list of conditions. The openssh-server package must be compiled without PAM (or the PAM-enabled variant must be set to UsePAM no), password authentication must be enabled, which is OpenSSH’s default setting, at least one account must have the marker “*” as its password, and at least one local account must have a password hashed in $5$ or $6$ format.
The cause: an error code mistaken for a password
The mechanism, detailed by Alpine, comes down to an unfortunate coincidence. Without PAM, sshd checks a password by hashing it with the crypt() function and then comparing the result with the stored value. For accounts whose stored value is too short to contain a salt, the program borrows another account’s salt. However, in musl, crypt() returns “*” to signal an error when the key exceeds 256 bytes. Since “*” is precisely the value recorded for accounts without a password, the comparison succeeds and the door opens.
The OpenSSH maintainers argue, in the 10.6p2 release notes published on 5 November, that the root cause lies outside sshd; they have nevertheless included a workaround that closes this exploitation path. The flaw was reported by Özgün Kültekin of the company Wakefield and fixed by Damien Miller and Darren Tucker.
Who is exposed
Alpine states that all of its checked versions are affected, from 3.21 to 3.24 as well as the edge branch, but also older versions, from 3.16 to 3.20. Fixed packages have been released back to 3.16, including for 3.21, whose support ended on 1 November. The root account, shipped with a “*” password since around version 3.16, can only be reached if PermitRootLogin yes is enabled, but another account able to become administrator is enough.
One case deserves particular attention: Alpine’s “tiny-cloud” cloud images, from 3.18.11 to 3.24.3, include an alpine user with no password who is allowed to use doas without entering one. Safe at first boot, they become vulnerable as soon as a $6$ hash appears on the machine, for example when an administrator sets a console password.
According to Alpine, the following are not affected: containers that do not run sshd, systems where password authentication is disabled, the PAM-enabled variant, accounts locked with “!” and cloud-init images configured without a password.
What administrators should do
- Update, then restart sshd. CERT-FR stresses that installing the package does not replace the daemon already in memory. On Alpine, the fixed versions include 10.3_p1-r2 for 3.24 and 10.2_p1-r1 for 3.23, and point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix.
- Failing that, disable password authentication after checking that key-based login works, while keeping a session open. If even that is impossible, CERT-FR recommends disabling the SSH service.
- Look for signs of intrusion. This means spotting in the logs any password-accepted logins on accounts that have no password, then checking doas usage, recently created accounts and authorised keys. Alpine advises treating the machine as compromised if a suspicious login cannot be ruled out.
For a business, the main difficulty is the inventory: Alpine servers often hide in forgotten virtual machines, appliances or cloud images deployed at scale. This blind spot is what needs to be addressed first.
Frequently asked questions
Is my Debian or Ubuntu server affected by CVE-2026-123158?
The conditions described by CERT-FR target Linux systems based on the musl library with PAM disabled. A server that does not meet these conditions falls outside the scope of the alert, but updating OpenSSH is still recommended.
Are Alpine-based Docker containers vulnerable?
Only if they run an SSH server. According to Alpine, a container that does not launch sshd is not exposed.
Is a restart needed after the update?
Yes. CERT-FR and Alpine point out that updating the package is not enough: the sshd service must be restarted for the fixed version to actually be running.
Sources
- [MàJ] Vulnérabilité dans OpenSSH (CERTFR-2026-ALE-015) — CERT-FR, 2026-11-06
- Security advisory: openssh-server password authentication bypass — Alpine Linux, 2026-11-05
- OpenSSH 10.6p2 (release-10.6p2) — OpenSSH, 2026-11-05