TL;DR: OpenSSH 10.6p2 closes a password bypass that could let a remote attacker log in to accounts with no password set on musl-based Linux systems without PAM, according to SOCRadar. Passwordless SSH accounts are only safe when authentication, account state and service configuration all align, not when any one layer is assumed to hold.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on SOCRadar's report: OpenSSH's musl and PAM handling created a password bypass that can expose passwordless accounts on Alpine-style systems.
Why it matters: This matters because SSH access controls can fail only on a specific runtime stack, so inventory, patching and log review have to account for the build, not just the service name.
By the numbers:
- OpenSSH 10.6p2 fixes the flaw, which SOCRadar says affects Linux systems running OpenSSH on musl with PAM disabled.
Context
Password authentication for SSH depends on more than a login prompt and a secret. On Linux, the server's PAM setting, the C library and the account's stored password state can combine in ways that create a bypass even when administrators think password logins are impossible.
This flaw matters most where OpenSSH is packaged into minimal images, appliances and embedded builds that use musl and disable PAM by default. In those environments, a passwordless account is often treated as key-only and therefore low risk, which makes the bypass more dangerous when the surrounding assumptions are wrong.
Key questions
Q: What should teams do first when SSH password bypass is exposed?
A: First, remove the password path on affected hosts by setting PasswordAuthentication no and confirming the effective sshd configuration. Then restart the service so the patched or hardened configuration is actually in force. If patching cannot happen immediately, disabling password login is the fastest way to break the exploit condition.
Q: Why do placeholder password fields create SSH login risk?
A: Placeholder password fields create SSH login risk when they leave a secret usable after a credential source has changed, or when operators assume the field is inactive and fail to rotate or remove it. A stale password can still authenticate over SSH if keyboard-interactive or password auth remains enabled, so account disabling, secret rotation and auth method checks matter.
Q: How does PAM change SSH password authentication?
A: PAM changes SSH password authentication by brokering the login through a privileged access workflow instead of exposing standing credentials. It can inject a just-in-time password, approve the session, record the login, and rotate the credential after use, which reduces shared password exposure and limits direct human knowledge of the secret.
Q: What signs suggest a passwordless SSH account was abused?
A: Signs include SSH sessions from unusual hosts or times, unexpected key additions in authorised_keys, new forwarding rules, altered shell history, and commands that match lateral movement or file transfer. If the account is passwordless, abuse often shows up as successful logins without password prompts, fresh private key use, or unexplained privilege escalation through sudo or group changes.
Technical breakdown
Why musl and PAM shape SSH password checks
sshd does not validate a password in isolation. Without PAM, it hashes the submitted secret and compares the result to the stored account value, so the C library's crypt() behaviour becomes part of the authentication path. On musl-based systems, that behaviour can diverge from glibc when hashes are truncated or malformed, which is why the same OpenSSH code path can be safe on one Linux family and exploitable on another.
Practical implication: Treat the libc and PAM combination as part of the authentication control, not just a deployment detail.
How an overlong password can match a passwordless account
The bypass depends on a password field that contains only the placeholder value used for accounts with no local password, together with another account that has a real SHA-256 or SHA-512 hash. A deliberately overlong password causes musl's crypt() to return a marker value that OpenSSH can treat as a successful comparison against the placeholder field. The result is not brute force in the usual sense, but a validation mismatch created by edge-case handling. See the SSH Key and SSH Certificate Management Guide.
Practical implication: Verify how your platform handles placeholder password fields and reject any configuration that still permits password-based SSH on those accounts.
Why default Alpine-style builds are the sharpest exposure
The dangerous combination appears in default or near-default builds where password authentication remains enabled, PAM is off and passwordless local accounts are present. That is common in minimal server images, cloud templates and appliance-style deployments that assume SSH key use only. Once those conditions line up, the exploit is remote, repeatable and easy to trigger with only an account name and a long password string.
Practical implication: Baseline images should remove password authentication entirely unless there is a documented operational need to keep it.
Threat narrative
Attacker objective: The attacker aims to gain authenticated SSH access to a passwordless local account and, on some images, pivot to root control.
- Entry occurs when a remote attacker sends an overlong password to an exposed SSH service running OpenSSH on musl without PAM.
- Credential access follows because the server accepts the malformed password as a valid match for an account with no password set.
- Impact is full interactive access to the targeted account, and in some Alpine cloud images that path can be used to reach root through passwordless doas.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Configuration-specific authentication failure is the real issue: this bypass is not a generic SSH problem, it is a stack-dependent validation failure that appears when OpenSSH, musl and PAM settings intersect in a narrow way. That makes the control boundary operationally fragile, because a package default can be safe on one Linux family and unsafe on another. Practitioners need to treat runtime composition as part of identity governance, not an implementation footnote.
Placeholder password fields create a false sense of safety: an account marked for key-only use can still become an authentication target when password handling accepts edge-case input against a stored placeholder. That is a governance gap, not just a parsing bug, because teams often assume a no-password account is outside the password-login threat model. The failure mode is a standing exception that survives until the service is restarted or the authentication method is removed.
Runtime identity exposure window: once the fixed package is installed, the vulnerable sshd binary can keep serving traffic until restart, which means remediation and exposure do not end at package upgrade time. This widens the operational window between remediation intent and actual enforcement. The practical response is to manage SSH as a live identity service with version, configuration and process state all under control.
Alpine-style cloud images illustrate how NHI and human access controls meet: a passwordless local account is often managed like a non-human access path, yet it can still become the bridge to full administrative control if the surrounding login policy is weak. SSH key and SSH certificate management becomes relevant here because the safer path is to remove password logins entirely and govern key-based access deliberately. The lesson is that account state and authentication method must be aligned, not assumed.
What this signals
Runtime authentication state now matters as much as package state: patching OpenSSH is necessary, but the effective risk only drops when the running daemon is restarted and password logins are removed. That shifts SSH governance toward live service state, not just image hygiene.
Key-only accounts need stronger lifecycle discipline: if an account is meant to be passwordless, its access path should be explicitly bound to keys or certificates and the password field should not be treated as a harmless placeholder. That is where SSH governance and SSH key and SSH certificate management overlap in practice.
Musl-based appliances and lightweight Linux images should be watched closely because they are often outside central identity controls. The pattern to expect is not noisy brute force, but a small number of successful password logins against accounts that were assumed to be key-only.
For practitioners
- Confirm exposed SSH stacks on musl builds Inventory Alpine, OpenWrt, Buildroot and Yocto systems that run OpenSSH server without PAM, then flag any host that still allows password authentication.
- Disable password logins where SSH keys are the only intended method Set PasswordAuthentication no across sshd_config and any drop-in fragments, then validate the effective setting before reopening access.
- Restart sshd after installing the fixed package Apply the updated openssh package, then restart the daemon so the patched binary is the one handling new sessions.
- Review authentication logs for password logins on passwordless accounts Search for Accepted password events involving accounts that should never use local passwords, then inspect follow-on doas use and recent account changes.
Key takeaways
- The flaw shows that SSH authentication can fail because of runtime composition, not just bad credentials or weak passwords.
- The exposure is narrow but operationally serious because it affects passwordless accounts on musl-based Linux systems without PAM.
- The limiting control is to remove password authentication, restart the daemon after patching, and verify that no password-based login path remains.
Related NHI Mgmt Group resources: SSH Key and SSH Certificate Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Azure Key Vault Contributor escalation 2024 · BeyondTrust breach 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The bypass is an authentication failure for passwordless local accounts on musl-based SSH hosts. |
| NHI-07 — Long-Lived Secrets | Password-based SSH access on accounts assumed to be key-only creates a standing login path that should not exist. | |
| Recommendation — Harden SSH authentication paths so no edge-case password validation can bypass the intended login policy. Remove password authentication from key-only SSH accounts and revoke any residual password path. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The exploit abuses authentication handling to gain valid credentials for a local account. |
| Recommendation — Map exposed SSH login paths to TA0006 and prioritise hosts that still accept password authentication. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account state and login method alignment are central to preventing this bypass from becoming usable access. |
| Recommendation — Review account login methods and remove password access from accounts intended for key-only use. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SSH logins must be governed by effective access permissions and authentication settings on the live host. |
| Recommendation — Enforce host-level authentication settings so the effective SSH policy matches the intended authorization model. | ||
Key terms
- sshole: sshole is the nickname given to CVE-2026-123158, a password authentication bypass in OpenSSH on musl-based Linux systems without PAM. It allows a remote attacker to authenticate to certain passwordless local accounts when the service configuration and libc behaviour line up in the wrong way.
- musl: musl is a lightweight C standard library implementation used by some Linux systems. It provides the runtime functions that compiled programs depend on for memory handling, string work, threading and system calls, and it is often chosen for small, static or container-focused environments because of its simplicity and size.
- doas: doas is a command used on Unix-like systems to run a command as another user, usually root, with a small configuration file. It is a privilege elevation tool that can replace sudo in some environments, using rules to decide which users may execute which commands and under what conditions.
- OpenSSH: OpenSSH is an open-source implementation of the SSH protocol for secure remote login, command execution, and file transfer. Administrators use it to control access to servers and network devices, so attackers often target weak keys, exposed services, and poor configuration. Defenders should enforce key-based authentication, restrict root login, and keep it patched.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the runtime and lifecycle conditions that make access paths safe or unsafe.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org