# OpenSSH 10.6p2 Closes a Password Bypass on Some musl Linux Servers

> MKNIRALO — Technology — CYBERSECURITY | OPEN-SOURCE INFRASTRUCTURE

- Published: 2026-11-06
- Estimated reading time: 8 minutes
- Byline: Niko — Cybersecurity, Semiconductors & Digital Infrastructure Observer
- Byline disclosure: Niko is a house editorial byline maintained by MKNIRALO, not a claim of an independently verified individual. It does not imply cybersecurity certification, security-clearance status, employment by a technology vendor or government, hands-on incident-response work, penetration testing or access to nonpublic systems. Articles distinguish official claims, technical disclosures, independently corroborated findings and unresolved attribution.
- Author profile: https://mkniralo.com/authors/niko/
- Tags: OpenSSH, CVE-2026-123158, Alpine Linux, Cybersecurity, Linux, Open Source, Security Updates
- Cover image: https://mkniralo.com/images/openssh-10-6p2-musl-password-bypass-cve-2026-123158.svg

OpenSSH 10.6p2 and Alpine patches address CVE-2026-123158, a password bypass limited to particular musl, non-PAM SSH configurations. Installing a fix is only half the job: the daemon must be restarted.

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)](https://www.openssh.org/releasenotes.html#10.6p2) — OpenSSH Project
- [Security advisory: openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [Urgent security release: 10.6p2 (OpenSSH developer announcement)](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) — OpenSSH Unix Developers mailing list / Damien Miller

## 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](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [Advisory for OpenSSH+musl users](https://www.openwall.com/lists/musl/2026/11/05/4) — musl mailing list / Rich Felker
- [A Critical SSH Password Bypass Hits musl-Based Linux](https://blog.checkpoint.com/exposure-management/a-critical-ssh-password-bypass-hits-musl-based-linux/) — Check Point Research / Check Point Blog

## 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](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [A Critical SSH Password Bypass Hits musl-Based Linux](https://blog.checkpoint.com/exposure-management/a-critical-ssh-password-bypass-hits-musl-based-linux/) — Check Point Research / Check Point Blog
- [Meet *sshole, the vulnerability that lets hackers SSH into Linux devices](https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password/) — Ars Technica

## 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](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [CVE-2026-123158 — GHSA-4fcc-vm97-gx3x (registry entry reproducing CVE record)](https://github.com/advisories/GHSA-4fcc-vm97-gx3x) — GitHub Advisory Database
- [A Critical SSH Password Bypass Hits musl-Based Linux](https://blog.checkpoint.com/exposure-management/a-critical-ssh-password-bypass-hits-musl-based-linux/) — Check Point Research / Check Point Blog
- [Meet *sshole, the vulnerability that lets hackers SSH into Linux devices](https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password/) — Ars Technica
- [OpenSSH flaw lets attackers log into password-disabled Linux accounts](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/) — BleepingComputer

## 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)](https://www.openssh.org/releasenotes.html#10.6p2) — OpenSSH Project
- [Security advisory: openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [Urgent security release: 10.6p2 (OpenSSH developer announcement)](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) — OpenSSH Unix Developers mailing list / Damien Miller
- [Advisory for OpenSSH+musl users](https://www.openwall.com/lists/musl/2026/11/05/4) — musl mailing list / Rich Felker

## 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](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux
- [Advisory for OpenSSH+musl users](https://www.openwall.com/lists/musl/2026/11/05/4) — musl mailing list / Rich Felker
- [CVE-2026-123158 — GHSA-4fcc-vm97-gx3x (registry entry reproducing CVE record)](https://github.com/advisories/GHSA-4fcc-vm97-gx3x) — GitHub Advisory Database
- [Meet *sshole, the vulnerability that lets hackers SSH into Linux devices](https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password/) — Ars Technica
- [OpenSSH flaw lets attackers log into password-disabled Linux accounts](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/) — BleepingComputer

## About this article

This article reflects the public sources available on the publication and update dates shown above. For developing stories, follow the linked source pages for subsequent statements or decisions.

## Sources and further reading

- [OpenSSH 10.6p2 release notes (5 November 2026)](https://www.openssh.org/releasenotes.html#10.6p2) — OpenSSH Project (published 2026-11-05) (accessed 2026-11-06)
- [Security advisory: openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) — Alpine Linux (published 2026-11-05) (accessed 2026-11-06)
- [Urgent security release: 10.6p2 (OpenSSH developer announcement)](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) — OpenSSH Unix Developers mailing list / Damien Miller (published 2026-11-05) (accessed 2026-11-06)
- [Advisory for OpenSSH+musl users](https://www.openwall.com/lists/musl/2026/11/05/4) — musl mailing list / Rich Felker (published 2026-11-05) (accessed 2026-11-06)
- [CVE-2026-123158 — GHSA-4fcc-vm97-gx3x (registry entry reproducing CVE record)](https://github.com/advisories/GHSA-4fcc-vm97-gx3x) — GitHub Advisory Database (published 2026-11-05) (accessed 2026-11-06)
- [A Critical SSH Password Bypass Hits musl-Based Linux](https://blog.checkpoint.com/exposure-management/a-critical-ssh-password-bypass-hits-musl-based-linux/) — Check Point Research / Check Point Blog (published 2026-11-05) (accessed 2026-11-06)
- [Meet *sshole, the vulnerability that lets hackers SSH into Linux devices](https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password/) — Ars Technica (published 2026-11-05) (accessed 2026-11-06)
- [OpenSSH flaw lets attackers log into password-disabled Linux accounts](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/) — BleepingComputer (published 2026-11-05) (accessed 2026-11-06)