On 5 November 2026 the OpenSSH project released 10.6p2 with what it calls a critical security workaround for Linux systems that use the musl C library with PAM disabled. The researcher who reported it published the details under the name *sshole. This article summarizes what is known, what to check on your hosts, and what evidence to preserve if you suspect abuse.

What happened

According to the OpenSSH release notes, sshd could allow a password authentication bypass on some Linux systems built and run with PAM support disabled. The OpenSSH team states that it considers the root cause to be outside sshd, but that the bug is exploitable through sshd and can be avoided there.

The researcher's write-up and reporting by BleepingComputer describe the mechanism. Accounts that must never use a password are normally locked by putting in the hash field of /etc/shadow. Since a is not a valid hash, no password should match it. Since 2016, sshd has hashed the supplied password even for such accounts, to avoid leaking valid usernames through timing differences. On musl, crypt() returns when it fails, and it fails for passwords longer than 256 bytes. sshd then compares the returned with the stored * and treats it as a match.

According to the researcher, the conditions are:

  • sshd runs on a musl-based system such as Alpine Linux, OpenWrt, Buildroot or Yocto
  • PAM is not used (the default in Alpine's openssh-server package)
  • SSH password authentication is enabled
  • at least one account has * as its hash
  • at least one other account has a real password hash

A password between 257 and 1024 bytes is then accepted for the locked account. Systems using glibc, such as Debian, Ubuntu and Fedora, and systems that authenticate through PAM are reported as not affected. We found no source reporting exploitation in the wild at the time of writing.

Why it matters

Locked accounts are everywhere: root on many minimal images, key-only deploy users, service accounts and directory users. Teams rely on the * entry as a guarantee. This bug turns that guarantee into nothing for the affected configuration.

The researcher notes that Alpine's official AWS and Azure images include a default alpine user that has passwordless doas, which would make a successful login equal to root. Musl is also common in container base images and embedded devices, which are often missing from asset inventories and patch cycles.

What defenders should check

  • Inventory hosts and images that use musl: Alpine, OpenWrt, Buildroot and Yocto builds, and container images based on Alpine that run sshd.
  • Check the sshd configuration with sshd -T and look at usepam and passwordauthentication.
  • Look for accounts with * in the second field of /etc/shadow.
  • Check the installed OpenSSH version. 10.6p2 contains the fix, and Alpine has published updated packages.
  • For external exposure, search your own address space and cloud accounts for port 22 on Alpine or embedded devices. Scope internet-wide searches to your organization only.

A quick local check on a suspect host:

sshd -T | grep -Ei '^(usepam|passwordauthentication)'
awk -F: '$2=="*" {print $1}' /etc/shadow

Detection ideas

These are starting points to adapt and test in your environment, not production-ready rules.

On the host, look for successful password logins. Accounts that should be key-only must never appear:

grep "Accepted password" /var/log/messages
grep '^alpine:' /etc/shadow

If the shadow field is * but the log shows a successful password login for that user, treat it as a likely exploitation.

In a SIEM that collects sshd logs, a generic query for password-based logins to accounts that are expected to be key-only could look like this (Splunk-style, adjust field names and the user list):

index=linux sourcetype=syslog "Accepted password for" (user=root OR user=alpine OR user=deploy)
| stats count min(_time) max(_time) by host user src_ip

Also review authentication events that precede a login, such as bursts of failed attempts from the same source address, and any new outbound connections or new files created shortly after a suspicious login.

Investigation

If you find a suspicious login, preserve evidence before you change anything:

  • Copy /var/log/messages, auth logs and any rotated logs, and the output of last and lastb if available.
  • Record the /etc/shadow entries and file timestamps, along with the sshd configuration in effect at the time.
  • Capture running processes, listening sockets and established connections.
  • Check for persistence: new authorized_keys entries, new users, cron entries, modified init scripts, and changes under /etc and /usr/local.
  • For the alpine user on cloud images, review doas configuration and the shell history of both the user and root.
  • In cloud environments, take a snapshot of the volume, and review instance metadata access and IAM activity from the instance role.

If you cannot confirm what happened, our compromise assessment and incident response teams can help you scope it.

Mitigation

  • Update OpenSSH to 10.6p2. On Alpine, run apk upgrade openssh and restart sshd.
  • If you cannot update right away, set PasswordAuthentication no in the sshd configuration and restart the service. Key-based logins keep working.
  • Prefer key-only access with a bastion or certificate-based SSH for administrative accounts.
  • Remove default accounts and passwordless privilege escalation from images you control.
  • Add musl-based images and devices to your vulnerability management scope, so the next fix reaches them.

The OpenSSH team also noted in its release that it will make more frequent releases because AI-assisted bug finding is increasing the volume of security reports. Expect shorter windows between disclosure and independent rediscovery, and plan your patching process for that.