An emergency OpenSSH release is prompting a focused security response among administrators of Alpine Linux and other musl-based systems. The issue is serious, but not universal: a password bypass arises only when several authentication and account-state conditions coincide. OpenSSH released 10.6p2 on November 5, and Alpine warned that a package upgrade without a service restart leaves the running SSH daemon unchanged. The vulnerability has since been registered as CVE-2026-123158; public proof-of-concept work should not be mistaken for confirmed attacks on real servers.

An emergency release for a particular class of SSH server

OpenSSH released portable version 10.6p2 on November 5, 2026, to block a password-authentication bypass on certain Linux installations using the musl C library without PAM. The project describes the change as a critical security workaround: the underlying interaction is not necessarily an OpenSSH defect in isolation, but an attacker can exploit it through the OpenSSH server. The release was prompted by a report from Özgün Kültekin of Wakefield. This is a server-side authentication issue, not a defect in every SSH client or every Linux machine.

Alpine Linux published a same-day security advisory and distributed corrected packages for its supported releases and several older branches. The practical warning is urgent for operators who expose SSH to a network, but the affected population is a subset of deployments. The distinction matters: presenting the advisory as a universal Linux password bypass would mislead administrators of systems that use a different C library, PAM authentication, or no password authentication at all.

Sources: OpenSSH 10.6p2 release notes (5 November 2026) · Security advisory: openssh-server password authentication bypass · Urgent security release: 10.6p2 (OpenSSH developer announcement)

The combination of settings that creates exposure

On Alpine, the relevant combination begins with an OpenSSH server running without PAM, with `UsePAM no` where that option applies, and `PasswordAuthentication yes`. The machine must also have a login-capable account whose stored password field is an asterisk (`*`), a common way to indicate an account intended for key-based access. Separately, there must be at least one local account with a SHA-256 or SHA-512-style password hash, recognizable by the `$5$` or `$6$` prefix. Check Point researchers further reported that the hashed-password account had to be active in their testing.

Those details narrow the alert. Alpine’s ordinary `openssh-server` build does not use PAM, while its PAM-enabled variant with `UsePAM yes` is outside the reported exposure. An Alpine container that never runs `sshd` is not an SSH target merely because its base image contains musl. Disabling password authentication removes the relevant pathway. Similarly, the locked-account marker `!` is not the same as `*`. Operators need to examine actual service configuration and account state, rather than treating a distribution name or version banner alone as proof of vulnerability.

Sources: Security advisory: openssh-server password authentication bypass · Advisory for OpenSSH+musl users · A Critical SSH Password Bypass Hits musl-Based Linux

How a password that should fail can appear to match

The problem sits at a boundary between an SSH authentication check and the C library’s password-hashing function. On a qualifying musl system, an unusually long attempted password can cause `crypt()` to return `*` as an error indicator. If the target account’s stored password field also contains `*`, the comparison can mistake that failure marker for a successful match. The publicly described demonstration uses oversized password inputs within the SSH protocol’s accepted range. A key-only account can therefore be reached through a password-authentication route that administrators expected to be unusable.

The bypass does not automatically provide root access on every affected host. OpenSSH normally prohibits root password login through the `PermitRootLogin prohibit-password` default. However, a reachable unprivileged account may have administrative rights through tools such as `doas`, making privilege escalation a separate and serious possibility. Nor is this a general compromise of SSH encryption or public-key cryptography. Its significance is more specific: a sentinel value intended to reject passwords can be confused with an error return in an authentication path.

Sources: Security advisory: openssh-server password authentication bypass · A Critical SSH Password Bypass Hits musl-Based Linux · Meet *sshole, the vulnerability that lets hackers SSH into Linux devices

CVE-2026-123158 is registered; exploitation evidence remains limited

The vulnerability is now tracked as `CVE-2026-123158`. The November 5 public CVE record, reflected in the GitHub Advisory Database, assigns a CVSS v3.1 base score of 8.1, classified as High. That corrects a timing discrepancy in early accounts of the incident: Alpine’s original advisory says no identifier had been assigned when it was written, and some contemporaneous coverage repeated that position. Those statements describe the situation at publication, not the later status of the registry entry.

A working technical reproduction is not the same thing as a confirmed attack on a real organization. The discoverer published vulnerability details, and Check Point reported laboratory testing that refined the necessary conditions. As of this report, the public materials reviewed did not establish independently verified exploitation in the wild, an identified victim, or an attributable intrusion campaign. That absence of confirmation must not be read as proof that no exploitation occurred. Administrators should investigate suspicious logins without claiming a breach merely because a vulnerable configuration exists.

Sources: Security advisory: openssh-server password authentication bypass · CVE-2026-123158 — GHSA-4fcc-vm97-gx3x (registry entry reproducing CVE record) · A Critical SSH Password Bypass Hits musl-Based Linux · Meet *sshole, the vulnerability that lets hackers SSH into Linux devices · OpenSSH flaw lets attackers log into password-disabled Linux accounts

Patch the package, then restart the running daemon

For Alpine administrators, the vendor’s immediate remedy is to install available fixed packages, for example with `apk upgrade -U -a`, and then restart the OpenSSH daemon using `rc-service sshd restart`. The restart is essential: replacing files on disk does not automatically replace the `sshd` process already handling connections. Alpine 3.24, for example, fixes the issue in `10.3_p1-r2`; the edge branch carries `10.6_p2-r0`. Other maintained branches use their own patched package revisions. Therefore, the absence of an upstream-looking 10.6p2 version string does not by itself mean the fix is missing.

If an update cannot be installed promptly, Alpine and OpenSSH advise disabling password logins with `PasswordAuthentication no` and restarting `sshd`. Before changing a remote host, operators should confirm working public-key access in a separate session and preserve their current connection while testing the new configuration. A failed reconnect could otherwise create an avoidable lockout. Other musl-based distributions should check their vendor’s patch status and service-management commands instead of copying Alpine package instructions blindly.

Sources: OpenSSH 10.6p2 release notes (5 November 2026) · Security advisory: openssh-server password authentication bypass · Urgent security release: 10.6p2 (OpenSSH developer announcement) · Advisory for OpenSSH+musl users

The verification that matters after the update

A useful response begins with an inventory of machines actually running OpenSSH, not an inventory of every system derived from Alpine. For reachable servers, confirm the effective password-authentication and PAM settings, determine whether passwordless-in-the-shadow-file accounts can log in, and check the vendor-specific corrected package revision. After patching, verify that the daemon has restarted and that intended SSH access still works. Published package tables and the actual running service are more reliable evidence than a remote banner used without context.

For potential past access, Alpine recommends looking for `Accepted password for` events involving accounts that were intended to be key-only, alongside unexplained privilege changes, new users or altered authorized keys. Logs alone may be incomplete, so an inconclusive audit should be described as inconclusive. The wider lesson is not that every Linux host is suddenly open: it is that a defensive marker can acquire a second meaning when software components disagree about error handling. Correcting the server and verifying the running state are the actionable conclusions.

Sources: Security advisory: openssh-server password authentication bypass · Advisory for OpenSSH+musl users · CVE-2026-123158 — GHSA-4fcc-vm97-gx3x (registry entry reproducing CVE record) · Meet *sshole, the vulnerability that lets hackers SSH into Linux devices · OpenSSH flaw lets attackers log into password-disabled Linux accounts