An OpenSSH authentication flaw can allow unauthorized SSH access on specific Linux systems using musl libc without PAM. Exploitation attempts have been observed. Administrators should verify exposure, apply the vendor fix and restart the SSH daemon.
On November 5, 2026, OpenSSH released version 10.6p2 to address a password-authentication bypass. The issue, tracked as CVE-2026-123158, can let an attacker access certain accounts without knowing a valid password. Alpine Linux is a particularly important affected distribution because its standard OpenSSH server package is built without PAM.
Alpine is also built on musl, a compact C standard library. A C library is the set of basic functions that programs rely on, including the one that hashes passwords. Red Hat’s builds use a different library, glibc, which matters later in this article.
This is not a universal OpenSSH compromise. A vulnerable system must meet several authentication and account conditions. But for affected systems, unauthorized account access can become a path to sensitive files or elevated privileges.
The OpenSSH release notes confirm the workaround. Alpine’s November 5 advisory identifies affected configurations, corrected packages and required remediation.
The vulnerability at a glance
| Detail | What the sources say |
|---|---|
| Identifier | CVE-2026-123158 |
| Disclosure | November 5, 2026 (the OpenSSH release and the Alpine advisory, which said no CVE identifier had been assigned yet) |
| Weakness | Password-authentication bypass |
| Relevant systems | OpenSSH using musl libc with PAM disabled, when the additional conditions below exist |
| Potential effect | Unauthorized account login, possibly followed by privilege escalation where account permissions permit it |
| Upstream correction | Portable OpenSSH 10.6p2 |
| Activity | Honeypot observations consistent with exploitation attempts, not proof of widespread compromise |
| Administrative action | Assess configuration, update packages, restart sshd (the SSH server program), examine suspicious authentication activity |
The conditions that make a system affected
Alpine identifies all of the following conditions in its affected configuration:
- The SSH server uses the non-PAM authentication path. This includes Alpine’s
openssh-serveror its PAM-capable build configured withUsePAM no. PasswordAuthentication yespermits the relevant password-login path.- A target account has
*in its password field. Such accounts may be intended for SSH-key access rather than password login. - At least one other local account has a
$5$(SHA-256) or$6$(SHA-512) password hash. - An attacker can reach the SSH service and has a usable target account name.
PAM stands for Pluggable Authentication Modules. It is a framework through which applications can use configured authentication mechanisms. The affected behavior occurs through a different path when PAM is disabled.
A system is not exposed through this specific path merely because it uses Alpine or contains the musl library. Containers that do not run sshd are not affected as SSH servers. Alpine lists PasswordAuthentication no and a PAM-enabled server with UsePAM yes among configurations not affected by this issue.
Red Hat reports that its products, including RHEL, are unaffected because their OpenSSH builds link against glibc and use PAM by default. Source: Alpine advisory and Red Hat CVE assessment.
How the bypass works
Linux typically stores a password hash, a value derived from a password, rather than the original password. Some accounts intentionally have no usable password hash. Their password field may instead contain a special marker, *, which should not permit a password login.
The musl library’s crypt() function can also return * as an error indication when given an unusually long password. In the vulnerable non-PAM OpenSSH password-checking path, that error result can be mistaken for a match with an account’s stored * marker. The additional presence of another local account using a compatible password hash is part of the reported conditions.
The result is a serious trust-boundary failure: an error from a lower-level library can be treated as proof of successful authentication, even though the account has no valid password. The OpenSSH 10.6p2 notes say the underlying cause is outside sshd, but the unsafe behavior can be prevented there.
This vulnerability illustrates a general software-security rule: an error status must never be interpreted as successful authorization or authentication.
Exploitation observations and what they prove
On November 8, the SANS Internet Storm Center reported long-password activity collected by its Cowrie SSH honeypots, decoy servers that record what attackers try. Its published counts were 58 on November 4, 232 on November 5, 713 on November 6, 246 on November 7 and 51 by the November 8 report update at 15:44 UTC.
These are long-password observations, not verified successful compromises or even exclusively CVE-specific attempts. SANS notes that some earlier activity was unrelated. It identified November 5 as the first recognizable use of the vulnerability-specific pattern. The partial November 8 count is not directly comparable to the complete earlier days.
The observation is sufficient to establish attack interest and justify rapid defensive action. It does not establish worldwide exploitation volume or the number of production systems compromised.
Patch versions and immediate mitigation
The upstream security correction is in OpenSSH 10.6p2. Linux distributors may backport that fix, which means applying it to packages that carry earlier upstream version numbers.
Alpine published these corrected package revisions:
| Alpine branch | Fixed OpenSSH package |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
Additional older branches are listed in the full Alpine patch matrix. Check the actual distribution advisory and installed package revision rather than assuming any version below 10.6p2 is unpatched.
For Alpine, its advisory gives this upgrade and service-restart sequence:
apk upgrade -U -a
rc-service sshd restartRestarting the running daemon is essential. Alpine explicitly warns that updating a package does not replace the already-running sshd process. Apply changes through an authorized maintenance process with a confirmed console or alternate management path.
If patching must be delayed, Alpine recommends disabling SSH password authentication by setting PasswordAuthentication no in the effective sshd configuration. Before restarting or reloading the service, verify SSH-key access and retain a working administrative session to avoid lockout. This is a temporary mitigation, not a reason to defer the security update indefinitely.
Investigating possible unauthorized access
Patching blocks the known vulnerable path going forward. It does not undo any previous unauthorized login.
For systems that met the exposure conditions, review SSH authentication records for successful password logins involving accounts intended to accept keys only. Also investigate unexplained account or authorized-key changes, privilege-elevation activity and suspicious file changes. A single unexpected log event deserves investigation but is not, by itself, proof that this CVE was exploited. Our article on what to do after an exploited fix covers the same principle for edge devices: a fix does not tell you who came through before it.
Alpine highlights an additional concern with certain official tiny-cloud images, Alpine’s cloud virtual machine images. Their alpine account can have no usable password while also holding passwordless doas privileges (doas is a tool that lets a user run commands as an administrator). Those images are not necessarily exploitable at first boot, but the affected combination of account and password-hash states can create elevated impact.
Alpine says images built from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 or later include the fixed package. Instances started from earlier images still need the package update or the password setting change. See Alpine’s impact and detection guidance.
What administrators should do now
Organizations operating Alpine or other relevant musl-based SSH deployments can work through five steps:
- Determine whether the documented conditions are present.
- Apply the vendor’s corrected package.
- Restart the actual SSH daemon, the running process.
- Verify the effective authentication configuration.
- Review authentication logs where prior exposure is plausible.
There is no basis to treat every OpenSSH installation as compromised. There is also no basis to assume an SSH-key-only account is protected if the server still permits a vulnerable password-authentication path. Teams that run no SSH server on Alpine or another musl system have no action to take for this specific issue and can treat it as a case study.
The immediate priority is configuration-specific assessment, vendor patching and verification of the running service.
Go deeper
- Alpine Linux security advisory, November 5, 2026: affected configurations, technical explanation, fixed versions, remediation and detection.
- OpenSSH portable 10.6p2 release notes, November 5, 2026: upstream workaround and technical boundaries.
- Red Hat CVE-2026-123158 assessment: distribution-specific applicability.
- SANS ISC, November 8, 2026: observed scanning and evidentiary limits.