OpenSSH Patches Authentication Bypass on Alpine Linux

OpenSSH has released an emergency fix for a critical authentication bypass vulnerability affecting certain Alpine Linux servers running the standard openssh-server package. Remote attackers with network access can log into passwordless accounts, such as key-only accounts, by submitting passwords between 257 and 1,024 bytes long. OpenSSH released version 10.6p2 to resolve the flaw, while Alpine Linux published fixed packages across supported and retired releases. System administrators managing affected Alpine infrastructure, including in Malaysia, should verify configurations immediately or report suspected compromises to the national Cyber999 response centre.

Key Facts

How Does the Password Bypass Vulnerability Work?

The vulnerability occurs when OpenSSH server processes passwords without PAM on systems using the musl C library. For accounts lacking a password, sshd borrows a salt from another account. When supplied with a password exceeding 256 bytes, musl returns an asterisk error indicator, which matches the stored password field and grants authentication.

Under default operations without PAM, sshd uses the crypt() function directly to evaluate incoming passwords against stored hashes. For accounts that have only an asterisk in their password field—indicating no password is set—the daemon borrows the salt of another local account possessing a valid hash starting with $5$ or $6$. Owing to changes introduced into musl in August 2012, passwords longer than 256 bytes cause crypt() to fail and return an asterisk rather than a null pointer. Because this error output matches the asterisk in the target account's password record, sshd treats the supplied credential as valid. The salt-borrowing behaviour stems from a July 2016 OpenSSH change designed to address CVE-2016-6210. The patch introduced in OpenSSH 10.6p2 blocks authentication if the stored hash field is shorter than four characters.

The vulnerability requires only a single connection attempt with an oversized password to successfully authenticate against an exposed account.

Which Systems Are Vulnerable to Compromise?

A server is vulnerable only when four specific conditions are met simultaneously. It must run OpenSSH without PAM, have password authentication enabled, host a passwordless account marked with an asterisk, and contain at least one other account possessing a hash starting with either dollar-five or dollar-six.

On Alpine Linux, the default openssh-server package is compiled without PAM, and password authentication is enabled out of the box. Passwordless accounts exposed by this flaw include SSH key-only users created via adduser or usermod -p '*', accounts populated via directory services using musl-nscd, the base root account (which ships as root:* since version 3.16), and the alpine account in official tiny-cloud images from releases 3.18.11 through 3.24.3. While the default PermitRootLogin prohibit-password configuration blocks direct root logins, an attacker logging into the alpine user can elevate privileges if passwordless doas permissions exist. Conversely, systems running OpenSSH with PAM enabled, glibc-based distributions, containers without sshd, accounts locked with an exclamation mark in /etc/shadow, and images configured through cloud-init are not vulnerable.

Linux distributions built on glibc and systems verifying credentials through PAM are completely immune to this authentication flaw.

Is the Vulnerability Being Actively Exploited?

No active attacks exploiting this authentication bypass have been reported. However, OpenSSH maintainer Damien Miller expedited the patch without a prolonged embargo because automated artificial intelligence agents have recently demonstrated the capability to independently discover identical software vulnerabilities within hours of discovery.

The flaw was reported by security researcher Özgün Kültekin of Wakefield, who also highlighted that other musl-based environments such as OpenWrt, Buildroot, and Yocto should be audited. Damien Miller urged administrators managing affected systems to set PasswordAuthentication=no or shut down SSH access immediately. Alpine's advisory recommends that administrators check /var/log/messages for lines recording Accepted password for accounts that should have no password, alongside reviewing doas executions, newly created user accounts, and modified authorized keys. The advisory notes that if an unauthorised login cannot be ruled out, the system must be considered compromised.

No security incidents leveraging this OpenSSH bypass had been detected prior to the emergency patch release.

What Should You Do?

• Apply Alpine package updates using apk upgrade -U -a and restart the SSH daemon immediately using rc-service sshd restart, as updating packages does not restart running services.
• Ensure OpenSSH is updated to version 10.6p2 or that Alpine installations run point releases 3.21.10, 3.22.8, 3.23.8, or 3.24.4.
• Disable password authentication immediately if updates cannot be applied: verify key-based access works, set PasswordAuthentication no across configuration files (including /etc/ssh/sshd_config and files in /etc/ssh/sshd_config.d), validate with sshd -t, and restart sshd.
• Audit system logs in /var/log/messages for any entry indicating Accepted password for passwordless accounts such as root, alpine, or key-only users.
• Treat the host as compromised and conduct forensic incident response if any unaccounted password logins are discovered.

Common Questions

Does this flaw affect standard Linux distributions like Ubuntu or Debian?

No. Systems built using the glibc C library or authentication mechanisms that route credential checks through PAM are not vulnerable. The issue specifically stems from interactions between OpenSSH and the musl C library used by Alpine Linux and select embedded environments.

Why does updating the package require an explicit service restart?

Upgrading the OpenSSH package on Alpine Linux does not automatically restart the running sshd process. Administrators must run the restart command manually to load the patched binary, or the active server will remain vulnerable despite showing an updated package version.

Are OpenWrt routers affected by this vulnerability?

Most OpenWrt installations are unaffected because OpenWrt uses Dropbear for SSH services by default, which does not contain this flaw. OpenWrt devices are only exposed if an administrator manually replaced Dropbear with the standalone OpenSSH server package under musl.

Sources and Methodology

This dispatch is based solely on reporting published by The Hacker News on 5 November 2026. ROCKSTARmedia Infosec has not independently reviewed, verified, or consulted secondary vendor advisories, third-party code repositories, or external technical write-ups.