*sshole: OpenSSH password bypass on musl Linux

What it means for your AI agents

The machines that run your agents, tool runners, sandboxes and MCP servers are hosts like any other. A host-level flaw reaches everything on the machine, including the provider keys and tool credentials your agents use.

• Include agent hosts, container nodes and code sandboxes in your patch inventory, not only your web servers.
• Containers share the host's kernel: rebuilding an agent's image does not fix a kernel flaw.
• If an affected host was reachable, rotate the model-provider and tool keys stored on it.

Updates

• Nov 5, 2026 : OpenSSH released 10.6p2, Alpine published fixed packages back to 3.16, and CVE-2026-123158 was assigned.

Details

When sshd is built without PAM, it checks a password by hashing the attempt with the C library's crypt() and comparing the result to the account's stored password field. Accounts with no password set store * in that field, which normally matches nothing.

musl's crypt() returns the string * as an error value when the password is longer than 256 bytes. sshd compares that * to the stored *, finds a match and accepts the login. The attack needs one other account on the machine with a $5$ or $6$ password hash, because sshd borrows its salt. One such account makes every account without a password reachable.

The flaw dates to 2016 and was reported by Özgün Kültekin of Wakefield. OpenSSH 10.6p2 adds a workaround in sshd; OpenSSH considers the root cause to be outside sshd. Alpine backported the fix to every branch from 3.16, so a lower OpenSSH version number does not mean a host is still vulnerable.

Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with no password and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash exists on the machine, for example after an admin sets a console password. An attacker can then log in as alpine and use doas to become root, even though root itself is reachable only if PermitRootLogin yes is set.

Not affected: glibc systems, Alpine's openssh-server-pam package with UsePAM yes, and accounts locked with !. According to Alpine, cloud images configured through cloud-init are not affected either, because cloud-init writes PasswordAuthentication no unless user-data sets ssh_pwauth: true.

Risk

With password logins enabled, an unauthenticated attacker can log in to passwordless accounts if another account has a $5$ or $6$ hash. Neither OpenSSH nor Alpine had reported exploitation as of November 6.

Affected deployments

Hosts running OpenSSH sshd before 10.6p2 and without their distribution's backported fix, on musl-based Linux such as Alpine (the researcher also lists OpenWrt, Buildroot and Yocto builds running OpenSSH) without PAM and with PasswordAuthentication enabled. Targets are accounts whose password field is * and directory-service users via musl-nscd, which have no shadow entry.

Recommended action

Update OpenSSH to 10.6p2 or your distribution's fixed package, then restart sshd. If you cannot update yet, set PasswordAuthentication no and restart sshd.

1. 1Find hosts running sshd on musl-based Linux, including Alpine VMs, cloud images, appliances and containers that run sshd. Check whether sshd uses PAM and whether PasswordAuthentication is enabled, including inside Match blocks in sshd_config and its drop-in files.
2. 2Update OpenSSH to 10.6p2 or your distribution's fixed package. On Alpine, run apk upgrade -U -a, then compare the version shown by apk list -I 'openssh*' with the advisory's fixed version for your branch. Alpine's fixed packages keep older version numbers, so sshd -V alone does not show the fix. Alpine Linux advisory

OpenSSH 10.6p2 release notes ↗

1. 1Restart sshd (rc-service sshd restart on Alpine). Upgrading the package does not replace the running daemon.
2. 2If you cannot update yet, set PasswordAuthentication no, including in any Match block that enables it. Check the configuration with sshd -t, restart sshd and confirm that sshd -T | grep -i passwordauthentication shows PasswordAuthentication set to no; for Match blocks, test with sshd -T -C user=…,host=…,addr=…. Keep an existing key-based session open while you test.
3. 3Check /var/log/messages for sshd lines reading Accepted password for an account with no password, such as alpine, root, a key-only user or a directory-service user. If you find one or cannot rule out a login, treat the host as compromised and review doas use, new users, changed files and authorized_keys.

Use this prompt with an agent that can inspect your infrastructure.

Check your exposure with an agent

Paste this into an AI agent that can see your infrastructure. It asks for a read-only check of what's affected, including the systems behind your agents, and a table you can act on. Copying it changes nothing.

Assess whether the infrastructure you can access is affected by *sshole: OpenSSH password bypass on musl Linux (CVE-2026-123158). Work read-only within your authorized access: do not run exploits, change configuration, restart services or install anything.

1. Confirm the affected and fixed versions from the vendor advisories and CVE records:
   - https://www.openssh.org/releasenotes.html#10.6p2
   - https://www.cve.org/CVERecord?id=CVE-2026-123158
   - https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
   - https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482
   - https://github.com/canonical/cloud-init/blob/26.2/config/cloud.cfg.tmpl#L63-L76
   - https://docs.cloud-init.io/en/latest/reference/modules.html#mod-cc-set-passwords
   Cite each source and the date you read it. Say plainly what you could not verify.

2. Inventory the systems that could run the affected software, including the hosts, containers, MCP servers, tool runners and sandboxes behind any AI agents. For each, record the asset, environment, owner if known and the version actually running, from read-only evidence (package metadata, version commands, platform inventory).

3. Note which affected systems are reachable from the internet or from agents and tools, and which credentials (model-provider keys, tool tokens, service accounts) are stored on them.

4. Report one row per asset: asset, running version, affected (yes / no / unknown), reachable from, credentials at risk, evidence, and the next step. List anything you could not access as a gap rather than assuming it is safe.