CVE-2026-123158: 
OpenSSH Analyse et atténuation de la vulnérabilité

CVE-2026-123158, nicknamed "SSHole", is a password authentication bypass vulnerability in OpenSSH's sshd daemon affecting Linux systems that use musl libc without PAM. On vulnerable configurations, any password between 256 and 1024 characters in length is accepted for certain accounts (e.g., accounts with a * or ! placeholder in /etc/shadow), allowing unauthenticated remote login. The vulnerability affects all OpenSSH versions before 10.6p2 on musl libc-based platforms; Alpine Linux is the primary real-world example. It was disclosed on November 5, 2026, with a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Red Hat Bugzilla).

The root cause lies in how musl libc's crypt() function handles strings that are not valid password hashes — specifically, when the password field in /etc/shadow is a placeholder like * (indicating a locked or password-disabled account), musl's crypt() misinterprets it and returns a hash that can match any sufficiently long input string (256–1024 characters). OpenSSH's sys_auth_passwd() in auth-passwd.c did not validate that the stored password field was actually a valid hash before comparing it to the encrypted candidate password, leading to a bypass (CWE-394: Unexpected Status Code or Return Value; CWE-303: Incorrect Implementation of Authentication Algorithm) (Github Advisory). The fix in commit 4353fdc adds a MIN_PASSWORD_HASH_LEN check (47 characters) to ensure the stored value is at least the minimum length of a valid hash before accepting authentication, and also adds proper memory management for the password string (OpenSSH Commit). The attack requires two password attempts within the same SSH connection — the first attempt primes OpenSSH's cached fake-salt, and the second attempt (>256 bytes) is then accepted (sshhole-repro). This issue is specific to musl libc without PAM; glibc-based systems (e.g., standard RHEL, Debian, Ubuntu) are not affected.

Successful exploitation allows an unauthenticated remote attacker to log in as any account whose /etc/shadow password field contains a non-hash placeholder (such as * or !), which typically includes locked accounts, service accounts, and — if PermitRootLogin yes is configured — the root account. This results in full confidentiality, integrity, and availability compromise of the affected system, including arbitrary command execution, data exfiltration, and potential lateral movement within the network (Github Advisory, Red Hat Bugzilla). Container environments based on Alpine Linux are particularly at risk, as Alpine is the most widely deployed musl libc distribution and is commonly used in Docker images with SSH enabled.

Public proof-of-concept (PoC) reproduction scripts are available, including a self-contained Docker-based PoC (repro.sh and repro_root.sh) that demonstrates successful authentication bypass against a locked account and root on Alpine Linux 3.15 (sshhole-repro). A lab environment for learning and experimentation is also publicly available (sshhole-lab). Multiple detection-oriented scanners have been published on GitHub. As of the disclosure date, no confirmed in-the-wild exploitation has been reported, and no threat actor attribution is available. The EPSS score is 0.0 (very early post-disclosure), and the vulnerability is not currently listed in the CISA KEV catalog. NVD SSVC assessment classifies exploitation as "poc" and notes the attack is not automatable due to the two-attempt requirement within a single connection (Github Advisory).

1. Reconnaissance: Identify internet-facing SSH servers running Alpine Linux or other musl libc-based distributions using tools like Shodan (port:22 product:OpenSSH) or Censys. Confirm the OpenSSH version is below 10.6p2 using ssh -V or banner grabbing.
2. Identify target accounts: Determine accounts with placeholder password fields (* or !) in /etc/shadow. Common candidates include locked accounts, service accounts, or root (if PermitRootLogin yes is set). This may require prior knowledge of the system or enumeration via other means.
3. Initiate SSH connection with two password attempts: Connect to the target using an SSH client configured for password authentication only, with NumberOfPasswordPrompts=2. The first attempt primes OpenSSH's internal fake-salt cache for the target account.
4. Submit a long password (256–1024 characters) on the second attempt: On the second prompt within the same connection, supply any password string between 256 and 1024 characters. Due to musl's crypt() misinterpretation of the * placeholder, the comparison succeeds and authentication is granted.
5. Achieve shell access: Upon successful bypass, the attacker obtains an interactive shell as the target user (e.g., uid=1001(victim) or uid=0(root)) and can execute arbitrary commands, exfiltrate data, or pivot to other systems (sshhole-repro, sshhole-lab).

Example command (from public PoC):

SSH_ASKPASS="./askpass.sh" SSH_ASKPASS_REQUIRE=force ssh \
  -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
  -o PubkeyAuthentication=no -o PreferredAuthentications=password \
  -o NumberOfPasswordPrompts=2 victim@<target> id < /dev/null

Where askpass.sh outputs a 300-character string (sshhole-repro).

• Network: Inbound SSH connections (TCP/22) where the client sends exactly two password authentication attempts in a single session, with the second attempt containing an unusually long password (256–1024 characters); connections from unexpected source IPs to SSH-exposed Alpine Linux or musl-based hosts.
• Logs: SSH authentication log entries showing a failed first attempt followed immediately by a successful login for the same user in the same session (e.g., sshd[PID]: Failed password for victim from <IP> then sshd[PID]: Accepted password for victim from <IP>); successful logins for accounts that are expected to be locked (shadow field * or !).
• File System: Unexpected files created in home directories of locked or service accounts; new SSH authorized_keys entries added post-compromise; web shells or backdoors if the attacker escalated further.
• Process: Unusual processes spawned under locked or service account UIDs (e.g., bash, sh, curl, wget); unexpected cron jobs or systemd timers created by non-interactive accounts.

Primary remediation: Upgrade OpenSSH to version 10.6p2 or later, which includes the fix in commit 4353fdc that validates the minimum hash length before accepting password authentication (OpenSSH Commit, Github Advisory). On Alpine Linux, run apk upgrade openssh to install the patched package.

Workarounds (if immediate upgrade is not possible):

• Disable password authentication entirely in sshd_config (PasswordAuthentication no) and use key-based authentication only.
• Restrict SSH access using firewall rules or network-level controls (e.g., AllowUsers, AllowGroups, TCP wrappers, or security groups) to limit exposure.
• Enable PAM (UsePAM yes) if supported by the platform, as the vulnerability only affects configurations without PAM.
• Monitor authentication logs for anomalous login patterns as described in the IOCs section (Red Hat Bugzilla).

The vulnerability attracted significant community attention shortly after disclosure, trending on Hacker News with multiple discussion threads (Github Advisory). The OpenSSH developer Damien Miller commented on the issue via Mastodon, and the OpenSSH team acknowledged the root cause lies in musl libc's behavior rather than OpenSSH itself, but released a workaround patch regardless. Security blogs including Security Boulevard, Cycode, OX Security, and CSO Online published analyses within hours of disclosure. The DevOps and container security communities expressed particular concern given Alpine Linux's widespread use as a base image in Docker environments. AUSCERT issued bulletin ASB-2026.0288, and HKCERT published a security advisory covering the vulnerability.