OpenSSH: password authentication can be bypassed on Linux systems using musl without PAM, CERT-FR warns

Top-Secured cyber watch: independent analysis based on the sources listed below. Top-Secured is not affiliated with the companies mentioned and will never ask you for your bank details or passwords.

OpenSSH released version 10.6p2 on 5 November 2026 to close a password authentication bypass in sshd affecting Linux systems built on the musl C library with PAM disabled, such as many Alpine servers and containers. CERT-FR issued an alert the same day, describing exploitation as trivial once the conditions are met.

What happened

On 5 November 2026, the OpenSSH project published portable OpenSSH 10.6p2, which fixes a password authentication bypass reachable through sshd. According to the release notes, the root cause lies outside OpenSSH, but sshd has been changed to avoid it. The same day, CERT-FR published alert CERTFR-2026-ALE-015, which covers all versions before 10.6p2 and calls exploitation trivial when the conditions are met. No CVE identifier is listed, and neither source reports attacks in the wild so far.

Who is affected

Only Linux systems that use the musl C library and run sshd without PAM are concerned. According to the researcher who found the flaw, musl’s crypt() function fails on passwords longer than 256 bytes and returns *, the very value that marks an account with no usable password in /etc/shadow. An attacker can then log in to such an account (key-only users, or root on recent Alpine releases, according to the researcher) with an overlong password, provided password authentication is enabled. The researcher lists Alpine, OpenWrt, Buildroot, Yocto and the Docker images built on them. Distributions based on glibc, setups using PAM, and Dropbear are not affected, according to the same write-up.

What to do now

  1. Find exposed systems: ldd --version prints musl on affected platforms; check sshd -T | grep -Ei 'usepam|passwordauthentication'.
  2. Update: apk upgrade openssh, then check that ssh -V reports 10.6p2. Rebuild and redeploy container images that embed sshd.
  3. If you cannot update yet, disable password logins with PasswordAuthentication no in a file under /etc/ssh/sshd_config.d/, then restart sshd (rc-service sshd restart). CERT-FR advises stopping the SSH service otherwise.
  4. Look for traces: list accounts whose password field is * (grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1) and look for Accepted password for lines about them in /var/log/messages, as CERT-FR suggests.

Our take

Lightweight images are everywhere in containers and appliances, and they inherit the defaults of their base system, PAM-less SSH included. Key-only authentication should be enforced explicitly in the configuration, not assumed: PasswordAuthentication no would have made this flaw harmless.

Sources

How we choose, verify and write our analyses →

Is your own server exposed? Run a free check — public information only, no intrusion:

Check a server Check a website

Worried your servers are exposed? Our team audits, patches and monitors Linux and cloud infrastructure 24/7.

Talk to an expert Our managed server services →