CVE-2026-123158 (*sshole): update musl-based OpenSSH servers now

What is confirmed

CVE-2026-123158, nicknamed *sshole, is a password-authentication bypass affecting OpenSSH server (sshd) before 10.6p2 on Linux systems that use the musl C library with PAM disabled. The upstream OpenSSH project released 10.6p2 on 5 November 2026 specifically to prevent the bypass.

The fault is not a general SSH protocol break and it does not affect every Linux distribution. It requires a particular combination: a musl-based system, an OpenSSH server without PAM, password authentication enabled, an account whose password field is a literal *, and at least one usable password hash from which sshd can obtain a salt. That combination is common enough on Alpine-derived and embedded deployments to deserve immediate review.

Vulnerability summary

CVSS is not the whole risk decision. An internet-reachable administrative endpoint and an affected account configuration raise the urgency considerably; an SSH service limited to a management network has lower exposure but still needs remediation.

How the bypass happens

On affected musl builds, a password longer than the supported limit can make crypt() return *. OpenSSH's timing-defence path can use a real account's salt when processing password authentication. If the target account's password field is also exactly *, the comparison can incorrectly succeed.

This is why the issue is configuration-dependent. A password-disabled account is not automatically vulnerable, and a server with PAM enabled is outside the confirmed affected scope. The bug can nevertheless turn a key-only or otherwise password-locked account into an SSH login path under the affected conditions.

Do not test this by attempting a bypass. Version, library and configuration inspection provide a safe answer.

Are you affected?

Start with the operating system and SSH configuration:

cat /etc/os-release
ldd /usr/sbin/sshd 2>/dev/null | grep -i musl || true
sshd -T | grep -Ei 'usepam|passwordauthentication'
sshd -V 2>&1

On Alpine, ldd /usr/sbin/sshd normally shows musl linkage. sshd -T shows the effective configuration, including settings inherited from sshd_config.d. Run it as root if required by your local configuration.

You need urgent action when all of the following are true:

1. The server runs musl, such as Alpine Linux or a derived/container/embedded image.
2. PAM is disabled or unavailable to sshd.
3. passwordauthentication yes is effective.
4. One or more local account password fields are exactly *.
5. The server exposes SSH to an untrusted network or a broad management network.

Do not copy password-hash data into tickets or chat. A privileged administrator can inspect the account state locally using the platform's normal account-management tooling. Treat LDAP, image-default and key-only service accounts as candidates for review as well.

Patch first

Install the vendor-provided OpenSSH update. On supported Alpine branches, Alpine's security tracker marks fixed packages including 10.6_p2-r0 for edge and backported package revisions for maintained branches.

apk update
apk upgrade openssh
rc-service sshd restart
sshd -V 2>&1

The expected result is an OpenSSH package version at or above the fixed package revision supplied for your Alpine branch. Before restarting a remote server, keep a second authenticated administrative session open and confirm your key-based access works. In clustered or immutable deployments, update the base image, rebuild, roll out progressively and verify the version on the running node rather than only in the build log.

For non-Alpine musl systems, use the distribution or firmware vendor's fixed package. Do not substitute a generic source build where the vendor has a supported security update unless that is your established maintenance process.

Temporary mitigation when a patch cannot be installed

Disable SSH password authentication until the fixed package is deployed:

printf '%s\n' 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-disable-password-auth.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Expected result: passwordauthentication no. This mitigates the vulnerable authentication path, but it can lock out users who rely on passwords. Confirm that all required administrators have working SSH keys or an out-of-band console before applying it.

To roll back after a tested package update, remove the temporary drop-in and restart sshd only if password authentication is an intentional business requirement. Keep it disabled where it is not needed.

Network restrictions, VPN-only management access and MFA gateways can reduce exposure, but they do not patch this defect. They are compensating controls, not a replacement for the update.

Verify the repair safely

After maintenance:

1. Confirm the installed package against your vendor's advisory.
2. Confirm the effective setting with sshd -T.
3. Establish a new key-based SSH connection from an authorised management host.
4. Check service health: rc-service sshd status on OpenRC systems.
5. Record the hostname, package revision, verification time and change reference in your patch record.

Avoid using malformed or oversized passwords as a verification method. The correct evidence is the fixed package version and a functioning, approved administrative login path.

Review for possible compromise

The site disclosure provides a defensive checker and advises reviewing SSH logs for a successful password login to an account that should not accept passwords. Log formats vary; preserve relevant authentication logs before rotation, then review successful SSH authentications, new accounts, changed authorised keys, unexpected privilege changes and unusual outbound activity.

A matching log entry is an investigation lead, not proof by itself. If an internet-reachable affected host shows suspicious authentication activity, treat it as a potential incident: isolate according to your response procedure, preserve logs and volatile evidence where possible, rotate credentials accessible from the host, and rebuild or restore systems when integrity cannot be established.

What is not confirmed

This article does not claim that every Alpine host, every OpenSSH version, or every account with a disabled password is vulnerable. The published scope is musl-based Linux with PAM disabled and the relevant password-authentication/account conditions. No primary source reviewed for this article confirmed active exploitation, and the CVE was not listed in CISA KEV at the time of checking. Those facts can change; recheck the sources below during remediation planning.

References

• OpenSSH 10.6p2 release notes — upstream fix and affected configuration.
• GitHub Advisory Database: CVE-2026-123158 — CVE and CVSS record.
• Alpine Linux Security Tracker: CVE-2026-123158 — fixed Alpine package revisions.
• The *sshole disclosure — technical explanation and defensive detection context.
• FIRST EPSS — score checked 6 November 2026.
• CISA Known Exploited Vulnerabilities catalog — checked 6 November 2026.

Change log

• 6 November 2026 — r1: Initial publication. Scope, package-remediation and exploitation-status statements verified against the listed sources.