As reported by The Hacker News, OpenSSH has issued an emergency patch for a critical authentication bypass vulnerability affecting Alpine Linux systems. The flaw, fixed in OpenSSH 10.6p2, allows attackers to log in to accounts with no password set by supplying a password between 257 and 1,024 bytes long. No active exploitation has been observed, but the conditions for exploitation are alarmingly common in default Alpine deployments.
Vulnerability Profile
| Field | Detail |
|---|---|
| CVE | Pending assignment at time of publication |
| Severity | Critical (per OpenSSH project rating) |
| Affected Software | OpenSSH server (sshd) built without PAM — primarily Alpine Linux's openssh-server package |
| Affected Alpine Versions | Alpine 3.16 through 3.24.3 (fixed packages now available for all) |
| Fixed Version | OpenSSH 10.6p2 |
| Active Exploitation | None reported as of November 6, 2026 |
| Root Cause | Interaction between sshd password verification and the musl C library |
Why This Matters
This vulnerability stands out because it weaponizes the intersection of two design decisions that, individually, are defensible: building OpenSSH without PAM and using musl libc for a minimal footprint. The problem is that Alpine's openssh-server package ships without PAM by default, and PasswordAuthentication defaults to yes. Combined with how musl handles long password buffers during crypt operations, an attacker can bypass authentication entirely for accounts whose password field is set to * — the standard marker for "no password set."
The attack is deterministic. It succeeds on every attempt with a single connection. And it doesn't require a passwordless account to be exposed in isolation — one account on the system with a real $5$ or $6$ hash is enough to expose every passwordless account on that host.
Who Is Most at Risk
alpine user has passwordless doas access. An attacker who compromises the alpine account can escalate to root.adduser without setting a password, or where users come from a directory service via musl-nscd with no shadow entry.PermitRootLogin yes — root ships as root:* in Alpine base images since 3.16, and while prohibit-password is the default, any system where this has been relaxed is directly vulnerable.The original researcher, Damien Miller of the OpenSSH project, was blunt: anyone running an affected system should "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."
Shield53 Recommendations
Immediate Actions
- Patch now. Upgrade to OpenSSH 10.6p2 via Alpine's package manager:
apk update && apk upgrade openssh. Fixed packages are available for all supported Alpine releases back to 3.16. - If you cannot patch immediately, disable password authentication. In
sshd_config, setPasswordAuthentication noand restart sshd. This is the single most effective mitigation and should arguably be the default in any hardened environment regardless of this vulnerability. - Audit passwordless accounts. Check
/etc/shadowfor entries with*in the password field. For key-only users, confirm that password auth is disabled system-wide. - Review doas/sudo configurations. On tiny-cloud images, the
alpineuser's passwordlessdoasaccess creates a direct root escalation path once this SSH flaw is exploited. Remove or password-protect doas rules for non-root users. - Restrict network access to SSH. Ensure sshd is not exposed to the public internet. Use firewall rules, SSH bastions, or VPN-only access. This vulnerability requires network access to the SSH port.
Broader Hardening
- Consider switching to the
openssh-server-pampackage if PAM-based authentication fits your environment — the PAM code path is not affected by this flaw. - Enforce key-based authentication organization-wide and disable password auth by policy, not just as a stopgap.
- Inventory all Alpine-based infrastructure, including base images for containers and VMs. Many teams may not realize they're running musl-based builds with the non-PAM OpenSSH package.
This is a reminder that minimal-footprint distributions like Alpine carry implicit assumptions about their build configuration. When those assumptions collide with default OpenSSH settings, the result can be a authentication bypass that requires no credentials, no exploit chain, and no special privileges — just a long string and a network connection.
