Alpine Linux and the OpenSSH development team published synchronized security advisories on November 5, 2026, warning of a critical authentication bypass in OpenSSH servers compiled without Pluggable Authentication Modules (PAM) support. The issue, reported by security researcher Özgün Kültekin of Wakefield, allows an unauthenticated remote attacker with network access to port 22 to gain shell access in a single connection without possessing valid credentials. No Common Vulnerabilities and Exposures (CVE) identifier had been allocated at the time the coordinated disclosure was issued.

The vulnerability arises from an interaction between the portable OpenSSH authentication logic and the musl libc implementation of the standard crypt() function. When sshd operates without PAM, it validates attempted passwords by hashing the provided string against the stored shadow entry in /etc/shadow. For accounts whose stored field is too short to contain a cryptographic salt prefix—such as accounts designated with an asterisk for SSH-key-only authentication—sshd borrows the salt from another existing account on the host. If an attacker submits a password payload between 257 and 1024 bytes in length, musl libc crypt() fails due to buffer boundaries and returns a literal asterisk string as an error indicator.

Because the stored hash field for key-only accounts is also recorded as an asterisk, sshd compares the returned error string against the shadow file value, observes an exact string equivalence, and immediately authenticates the session. Consequently, the presence of a single legitimate user account with a standard SHA-256 ($5$) or SHA-512 ($6$) password hash renders every passwordless or key-only account on the machine susceptible to remote unauthorized login. In Alpine base environments, the root account has shipped with an asterisk password field since Alpine 3.16, though default PermitRootLogin settings restrict direct root logins unless explicitly reconfigured.

Cloud environments face heightened exposure through official tiny-cloud images spanning versions 3.18.11 through 3.24.3, which configure a default alpine user possessing an asterisk password field paired with passwordless doas administrative rights. While dormant on initial boot, these instances become remotely vulnerable as soon as an administrator configures a local hashed password for another user or runs scripts that write a shadow hash. An attacker targeting the alpine account can bypass authentication instantly and execute doas to assume unrestricted root control over the host.

Remediation requires updating the openssh package to patched releases, such as 10.6_p2-r0 on Alpine edge or 10.3_p1-r2 on Alpine 3.24, followed by an immediate restart of the sshd daemon via rc-service sshd restart. Upgrading the disk binary alone does not terminate or replace the running process. Organizations unable to reboot or restart immediately can eliminate exposure by appending PasswordAuthentication no to /etc/ssh/sshd_config or a drop-in file and reloading sshd configuration. Maintainer Natanael Copa generated patched packages extending back to unsupported legacy release Alpine 3.16.

The OpenSSH project simultaneously released portable OpenSSH 10.6p2 containing internal safeguards to reject password validation against short or anomalous shadow fields. In accompanying release notes, maintainers Damien Miller and Darren Tucker observed that the project has received an influx of security defect reports identified through AI code analysis models. The team confirmed that multiple security flaws surfaced by automated AI auditing were independently uncovered by separate external researchers, prompting OpenSSH maintainers to adopt a more frequent release cadence to deliver critical fixes into production environments faster.