OpenSSH: authentication bypass on musl systems without PAM

On 5 November 2026 the OpenSSH project released version 10.6p2, together with a security bulletin about a vulnerability that allows an attacker to bypass the authentication of an SSH service. On the same day CERT-FR (ANSSI) issued two documents: advisory CERTFR-2026-AVI-1468 and alert bulletin CERTFR-2026-ALE-015. Both list OpenSSH versions prior to 10.6p2 as affected and classify the risk as a security policy bypass.

Both sources for this article come from CERT-FR. The advisory only gives the affected versions and the remedy; the exploitation conditions, the indicators and the mitigation come from the alert bulletin alone. Neither document gives a CVE identifier or says whether the vulnerability is already being exploited.

Conditions for exploitation

According to the CERT-FR alert bulletin, the vulnerability affects Linux systems that meet both of these conditions:

• they use the musl standard C library;
• OpenSSH is compiled without PAM support, or PAM is disabled.

In this configuration an attacker can log in by supplying two passwords, the second one strictly longer than 256 characters and shorter than 1,024. CERT-FR writes that, when the conditions are met, exploitation is trivial, and urges administrators to check whether their systems are in a vulnerable configuration.

The bulletin does not describe the flaw in the code and does not mention any other affected configuration. For details it refers to the OpenSSH bulletin for version 10.6p2 and to the page of the researcher who found the flaw, called “sshhole”.

Indicators of compromise

The researcher, CERT-FR reports, recommends checking the legitimacy of logins for every system account that has an asterisk in /etc/shadow instead of a password (:*:, password disabled). The bulletin suggests this command, to be run as root:

awk -F : '$2 == "*" {print $1}' /etc/shadow | xargs -r -I{} grep "Accepted password for {}" /var/log/messages

The command lists the accounts with a disabled password and searches the /var/log/messages log for successful password logins in their name. Every result must be checked: it is a password login accepted on an account whose password is disabled. If sshd messages on your systems go to a different log, adjust the path in the command.

Impact for European and Italian companies

OpenSSH is the standard tool for remote administration of Linux systems, and the SSH service is often reachable from the Internet. The vulnerability does not affect every installation, though: according to CERT-FR it requires both the musl library and PAM being absent or disabled. The first step is therefore an inventory: which systems run OpenSSH older than 10.6p2, which use musl, how PAM is configured and whether password authentication is accepted.

An SSH service whose authentication can be bypassed is direct access to the system: it must be handled as a priority, starting with servers reachable from outside. For NIS2 entities the case falls under vulnerability handling and the control of administrative access required by the security measures; it is worth documenting the inventory, the log checks and the decisions taken for each system.

What to do now

1. Update OpenSSH to version 10.6p2, or to your distribution’s package that includes the fix, following the OpenSSH bulletin as CERT-FR advises.
2. Check the configuration of systems you cannot update right away: C library in use (musl or another), OpenSSH compiled with or without PAM, and the effective value of the UsePAM directive, which you can read with sshd -T.
3. If you cannot update, CERT-FR recommends disabling password authentication (in sshd_config, PasswordAuthentication no, then reload the service) or, failing that, disabling the SSH service. Before removing passwords, make sure administrators can log in with keys, so you do not lock yourself out.
4. Look for traces with the command from the bulletin and, more generally, review successful password logins from unusual addresses or at unusual times, especially on system accounts.

How ARXDOME helps

ARX Sentry collects the software inventory and login logs from Linux servers: it helps find the machines running OpenSSH and see their version, and its identity pages show successful, privileged and night-time logins. ARX Expose and ARX Scout show which of the company’s public addresses expose an SSH service, that is, where to start with updates and checks.

Last updated: 5 November 2026