OpenSSH Flaw Could Let Attackers Bypass Password Authentication on Alpine Linux Servers

A critical OpenSSH flaw could let remote attackers bypass password authentication on affected Alpine Linux servers, including accounts intended for key-only access. OpenSSH released Portable 10.6p2 on November 5, 2026, to block the issue, which affects Linux systems using musl libc without PAM authentication.

Research published on sshhole.com by Özgün Kültekin of Wakefield explains how an unusually long password can turn a failed password check into a successful login. Alpine confirms that exploitation needs one connection, a reachable SSH port, and a known account name when the required conditions exist.

The target account must have * in its password field, while another local account must contain a $5$ or $6$ password hash. Password authentication must also remain enabled. This means adding a password to one account can expose other accounts that were created without passwords.

Alpine’s standard openssh-server package does not use PAM, making the configuration important. Systems using openssh-server-pam with UsePAM yes are unaffected. Containers without a running SSH server are also unaffected, so using an Alpine container image alone does not establish exposure.

The disclosure follows earlier OpenSSH 10.6 security fixes, but this issue concerns password checks rather than encryption. No CVE identifier had been assigned when Alpine published its advisory.

OpenSSH Flaw Bypass Password Authentication

The researcher’s technical analysis traces the failure to an interaction between OpenSSH and musl’s crypt() function. Without PAM, sshd hashes the submitted password and compares the result with the stored password field. For an account whose field contains only *, sshd borrows another account’s salt.

When the submitted password exceeds 256 bytes, musl’s relevant password-hashing code rejects it and returns * as an error marker. That marker matches the target account’s stored field. Instead of rejecting the login, the comparison succeeds. Alpine identifies passwords between 257 and 1024 bytes as the trigger.

On vulnerable systems, a password consisting of 300 repeated ‘A’ characters could bypass authentication for an affected account. The password does not need to match a real secret. Instead, its length triggers an error in musl’s password-hashing function, which returns the same * marker stored for that account.

The comic from researcher shows how separate changes to password handling came together over time. It connects the use of * for accounts without usable passwords, musl’s matching error marker, and OpenSSH’s borrowed-salt behavior. Together, these explain how a long password could pass a check that should have rejected it.

The researcher links the chain to a 2016 OpenSSH change designed to reduce username discovery through timing differences. Testing across library and authentication settings exposed the musl-without-PAM mismatch. This is distinct from earlier OpenSSH client and server vulnerabilities involving interception and service disruption.

Official Alpine tiny-cloud images from 3.18.11 through 3.24.3 contain an alpine account with passwordless doas access. They become exploitable when a qualifying password hash is added. An attacker could then log in as alpine and become root. Default restrictions still block direct root password login unless administrators change them.

Follow Alpine’s remediation guidance by running apk upgrade -U -a, then rc-service sshd restart. Updating alone leaves the old daemon running. Fixed releases include 3.21.10, 3.22.8, 3.23.8, and 3.24.4, with patched packages available for older branches.

Older branches also received patched packages, so a lower OpenSSH version number does not automatically mean a system remains vulnerable.

Where patching must wait, set PasswordAuthentication no, confirm key-based access works, and restart sshd while keeping an existing session open. Review /var/log/messages for Accepted password for entries involving passwordless accounts, then inspect unexpected doas activity and new authorized keys.

The OpenSSH release notes confirm the upstream workaround. Alpine advises treating machines as compromised when unauthorized access cannot be ruled out.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.