CVE-2026-123158 SSHole: Alpine OpenSSH Exposure Checks and Fixes

Need a repeatable testing workflow for your own environment? Try Penligent for an authorized security test and keep the scope, findings and remediation evidence together. Use the vendor checks below to establish this CVE’s status.

If you run OpenSSH’s server on Alpine Linux, check both the installed package and the daemon accepting new connections. Alpine shipped patched packages for CVE-2026-123158, also searched as SSHole, on November 5, 2026, but upgrading the package does not restart a running sshd. A host can therefore show a fixed version in its package database while an older process still serves SSH. Alpine’s security advisory calls for an upgrade and an explicit restart.

The bypass is narrower than “all OpenSSH servers” or “all Alpine containers.” It concerns a password-authentication path on Linux with musl and PAM disabled, and it requires a particular combination of account states. You do not need to attempt a bypass to triage a host or verify that the vendor fix is running.

How OpenSSH, musl, Alpine Linux and Secure Shell relate

Secure Shell (SSH) is the protocol. OpenSSH supplies an implementation, including the sshd server and ssh client. musl is the C library used by Alpine Linux, a distribution that packages these components. This incident concerns a particular server authentication path across those components; it does not establish a failure in the SSH protocol or every application linked to musl.

Start with the asset that actually accepts connections. An Alpine application container with no SSH daemon is a different scope from an Alpine host running one. A developer’s OpenSSH client version is also different evidence from the server package, its authentication configuration and its running listener.

SSHole exposure checks for Alpine Linux and musl

Portable OpenSSH 10.6p2 adds a workaround in sshd. Alpine explains that musl’s password hashing function can return a failure marker that equals the stored * field of an account with no password set. An affected OpenSSH path could mistake this equality for successful authentication. The published CVE record describes the musl/non-PAM condition. Alpine’s post predates assignment of the CVE; that timing difference does not describe a second vulnerability.

Use this table for unpatched listeners. Evaluate the conditions together for the actual source network and account you are reviewing.

Default PermitRootLogin prohibit-password blocks password authentication directly as root, but does not protect a different account that can elevate with doas. Conversely, a * field alone is not evidence of a reachable login. Account rules, additional authentication requirements, and the listener’s network scope still apply. Treat unknown conditions as unverified, not as either “safe” or “exploited.”

Start your first authorized test with Penligent.

Check the effective configuration without exposing credentials

On a system you administer, identify the active configuration file and launch flags from the service definition first. These read-only examples assume the default config path; mirror a custom -f path and relevant service overrides if present. Replace the example account, client address and destination with the real authorized scenario. OpenSSH’s daemon manual documents the configuration test modes and connection inputs.

cat /etc/alpine-release
apk info -v | grep -E '^openssh(-|$)'
sshd -t
sshd -T -C 'user=reviewuser,host=admin.example,addr=192.0.2.10,laddr=192.0.2.20,lport=22' \
  | grep -E '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods|pubkeyauthentication|allowusers|denyusers|allowgroups|denygroups) '

Repeat sshd -T -C for applicable Match cases. This evaluates what a new daemon using those inputs would load; it does not read settings out of the currently listening process. A no-PAM build may not expose a useful usepam line, so inspect the installed build rather than inferring PAM mode from an empty grep result.

For a privileged operator reviewing local accounts, the following example prints only counts. It neither prints hashes nor tests any login. It does not enumerate directory-backed identities, identify which accounts can use SSH, or establish exposure by itself.

awk -F: '
  $2 == "*" { star++ }
  $2 ~ /^\$[56]\$/ { sha_crypt++ }
  END { printf "local_star_fields=%d\nlocal_sha_crypt_fields=%d\n", star, sha_crypt }
' /etc/shadow

If the account source is a directory or another identity backend, have its owner validate the relevant account types. Keep shadow-file contents, private keys, and credential material out of tickets and reports.

Alpine fixed package versions

Compare the complete Alpine package revision against the threshold for the asset’s branch. The Alpine advisory lists the following versions; the stable branches have backports, so an upstream banner below 10.6p2 does not by itself mean an Alpine package is vulnerable.

Bu point-release announcement identifies the four new images/releases. A backport for an older branch is an immediate fix for this issue, not a return to supported status. Plan migration separately. For independently built packages or binary copies not managed by Alpine’s repositories, ask the supplier for patch provenance; these revisions are not a lookup table for custom builds.

Cloud images and containers: verify the running asset

Alpine specifically describes its official tiny-cloud qcow2, VHD and AMI images from 3.18.11 through 3.24.3. The default first-boot state is not exposed under the advisory’s conditions, but the images contain an alpine account with a * password field and passwordless doas. Setting a console password or adding a hashed password through provisioning can introduce the missing prerequisite. If the remaining conditions also hold, the resulting access can be more consequential than a low-privilege login.

Inspect what user-data, image customization, or later account changes actually applied. Alpine identifies cloud-init configurations that disable SSH password authentication as outside the described path; verify the effective setting on the running guest. A newly published image fixes future deployments only after you use it. It does not replace packages or processes in existing instances. For a container that intentionally runs sshd, rebuild from a patched base or package set and verify that the old replica no longer receives traffic.

Close the change with package, process, and access evidence

1. Prepare recovery before the change. Confirm an authorized fresh key-based login and an out-of-band or console recovery path. Keep the current administrative session open; do not rely on it surviving a restart. Inventory any automation that depends on password authentication.
2. Apply the branch-matched fix. Use your approved Alpine update path and record the installed server revision on each asset. Do not use ssh -V as server evidence: it reports the client. If an immediate update is not possible, Alpine recommends setting effective PasswordAuthentication no, validating the intended config and restarting. Treat this as containment, not patch completion. Do not change hash or account states as a substitute for the vendor fix.
3. Replace the listener. Validate the intended config with sshd -t before restarting. Alpine documents rc-service sshd restart for the OpenRC-managed service. Use the real supervisor or rollout mechanism if different. Compare service identity and listener process before and after, and check startup logs and the bound endpoint. For multiple replicas, verify each serving instance, not only a single successful connection.
4. Prove intended access from a fresh connection. Open a separate authorized connection without reusing an SSH multiplexed session. Check expected key-based access, and capture the effective configuration for applicable identities and source networks. If password auth is intentionally disabled, effective policy evidence plus a valid key control is safer than trying a bypass or guessing passwords. An old session staying connected is not proof that new connections reach the replacement daemon.

A concise change record should contain the asset and branch, package revision, maintenance time, old/new listener identity, config check result, and the timestamp and result of the fresh control login. If mitigation is the only closure available, record it separately and leave the package remediation open. Avoid entering usernames, raw secret material, or unnecessary topology in a broadly shared record.

Review the exposure window separately from patch status

Alpine suggests reviewing sshd authentication logs for successful password logins on accounts that should never use passwords. Check /var/log/messages where applicable and your actual centralized or rotated logs. Correlate account configuration history with doas activity and unexpected changes to users or authorized keys. Preserve evidence and escalate unexplained logins through your incident-response process. A patched listener does not close a historical investigation; an absence of alerts does not establish that earlier activity did not occur.

See a general authorized-testing workflow

The Penligent product demonstration offers general context for teams evaluating an AI-assisted testing workflow. This video is not a recording of the OpenSSH checks above and does not demonstrate this bypass, a server upgrade, or successful remediation. Keep the maintenance decision tied to branch-matched package evidence, the replacement listener and an authorized fresh connection.

Method: AI-assisted review of upstream and distribution advisories, patch evidence, and documentation on November 6, 2026. The checks above are a proposed operator runbook; no host, package installation, or login was tested for this article.