OpenSSH on Alpine Linux: attackers can log in over SSH without knowing the password

What happened

On 5 November 2026 the OpenSSH project released version 10.6p2. The release notes describe it as a fix for a password authentication bypass in sshd that affects some Linux systems built and run without PAM. The developers say the root cause lies outside sshd, but because sshd is where it can be exploited, that's where they worked around it.

The flaw is tracked as CVE-2026-123158. According to the NVD record, sshd misjudges whether the string stored for an account is a password hash, and for some account configurations any password between 256 and 1024 characters is accepted. NVD names Alpine Linux as an example of an affected platform. Alpine is a popular base for Docker images and small cloud VMs, so the exposure is wider than it might first appear.

Alpine published its own advisory and fixed packages the same day. It says an attacker who can reach the SSH port can log in without knowing a password.

The CVSS score isn't higher only because several conditions have to line up. When they do, the attacker gets a shell with no password at all.

Exploitation in the wild. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 9 November 2026 and gave US federal agencies until 12 November to fix it. GreyNoise, which runs vulnerable sensors (honeypots), recorded the first successful exploitation at 00:46 UTC on 7 November, less than two days after the first public proof of concept appeared. By 10 November it had logged 20 sessions with confirmed post-exploitation activity from six attacker IP addresses; by 13 November that had grown to 42 chains from 10 addresses, the latest on 12 November. Once in, the attackers checked whether they were inside a container, queried AWS, Azure and Alibaba Cloud metadata services, used doas to try to read /etc/shadow and root's SSH keys, added their own keys to authorized_keys, edited /etc/hosts and /etc/resolv.conf, and deployed a Python agent that beaconed to a command-and-control server. GreyNoise warns that because SSH is encrypted, its numbers probably undercount the real activity.

Technical details

Alpine's advisory explains the mechanism. When sshd is built without PAM, it checks a password itself: it runs the attempt through the C library's crypt() function and compares the result with the hash stored in /etc/shadow.

Two things go wrong together on musl:

• Accounts without a password have nothing to salt with. An account whose shadow field is just * has no hash and no salt. In that case sshd borrows the salt from another account on the system that does have a password hash. That's why the attack needs at least one local account with a $5$ (SHA-256) or $6$ (SHA-512) hash.
• musl signals an error with an asterisk. For keys longer than 256 bytes, musl's crypt() gives up and returns * as its error marker.

So with a long enough password, the "hash" sshd computes is *, the value stored for the passwordless account is also *, and the comparison matches. The login succeeds. Accounts locked with ! aren't affected, because their field doesn't match the error marker.

What this means for defenders:

• No login and no user interaction. The attacker only needs network access to the SSH port and the name of an account with * in its password field – on newer Alpine base images that can be root, though root is only reachable when PermitRootLogin yes.
• Not automatable at scale on its own. CISA's SSVC entry in NVD rated it as not automatable, because the conditions vary between systems. Real attacks started within two days anyway (see above), so don't treat that as a reason to wait.
• The fix is in sshd. OpenSSH 10.6p2 and the patched Alpine packages stop sshd from accepting this case, even though musl's behaviour itself hasn't changed.

We're not publishing anything that would help reproduce the attack. Public proof-of-concept repositories exist and are referenced from the NVD record, which is one more reason to patch quickly.

Who is affected

Mainly anyone running Alpine Linux with an SSH server. Alpine says it checked supported releases 3.21 to 3.24 and edge, plus the unsupported 3.16 to 3.20, and all were affected. Other musl-based distributions that build OpenSSH without PAM may be affected too. Glibc-based distributions such as Debian, Ubuntu, Fedora and RHEL aren't covered by the description.

It isn't only Alpine. On 9 November, Medcrypt wrote on the oss-security list that it had reproduced the flaw independently on a stock Yocto image with no unusual configuration. Yocto is widely used to build firmware for embedded devices, and Medcrypt says the combination of musl, no PAM, password authentication and locked service accounts is common there. If you run devices with vendor-built Linux firmware and SSH, ask the vendor about a fix.

According to Alpine, all of these have to be true:

• password authentication is enabled (PasswordAuthentication yes, the OpenSSH default),
• you use the openssh-server package (no PAM), or openssh-server-pam with UsePAM no; the PAM variant with UsePAM yes isn't affected,
• at least one account has * in its password field – for example key-only users, directory-service users, or root in base images since around 3.16,
• at least one other local account has a $5$ or $6$ password hash.

Alpine singles out its tiny-cloud cloud images from 3.18.11 to 3.24.3. They come with an alpine user that has * instead of a password and passwordless doas. They become exploitable as soon as any account on the machine gets a $6$ password hash.

How to tell if you were compromised

OpenSSH and Alpine haven't published indicators, but GreyNoise has listed the addresses that successfully attacked its sensors (defanged below). The first two are members of the same GreyNoise-tracked cluster (GT10), linked with high confidence but without an attack of their own on GreyNoise's sensors:

152.175.65[.]88
202.155.94[.]33
20.255.63[.]133
20.2.81[.]241
47.80.65[.]43
209.248.50[.]17
79.116.138[.]30
183.220.91[.]15

More addresses have appeared since 11 November; GreyNoise's page has the full list. On 12 November the attacker at 140.245.33[.]114 (Oracle Cloud, AS31898) became the only one seen leaving persistent access behind: its own keys in /root/.ssh/authorized_keys and /home/alpine/.ssh/authorized_keys, a /root/.sshole/pwned.txt marker and a program registered as two OpenRC services. The names mimic Alpine's legitimate tiny-cloud tool, so go by path and hash rather than name. Files according to GreyNoise (SHA-256):

811362311f13ac4bdc42fe4e7650aca618a68e3a40f930de88536d18b14d2b52  /usr/libexec/tiny-cloud/cloud-agent
02341e1e5917ccb2ea42686560554140f35f30af50f86162ad5d88649314228c  /usr/libexec/tiny-cloud/sync.py
96cf2735cabab0628310fb40a0a560421d5da98d2ca315baaf6891dd1ca338fa  /etc/init.d/tiny-cloud-agent
6e6f45e22f9c26595da5116f06dd7388df93d2d4a3bd7f90eeae93ac155dc7ba  /etc/init.d/tiny-cloud-sync
d70cbd1b206accf0bc99ca9273d9204e6d6fba61b33ee94ff0196d8910c79e1b  /root/.sshole/pwned.txt

rc-update show lists the services set to start at boot – look for tiny-cloud-agent and tiny-cloud-sync.

The agent's command-and-control domain, according to GreyNoise, is tac.vpnla[.]org. Block the domain rather than its IP address, which is a shared Cloudflare address.

Alpine recommends these checks:

• Password logins by passwordless accounts. Search /var/log/messages for Accepted password for and compare the usernames with accounts that have * in /etc/shadow. A successful password login for such an account shouldn't be possible on a healthy system.
• Privilege escalation. Review doas usage, especially by key-only or cloud-init users.
• Persistence. Look for recently created users, unexpected files and new keys in authorized_keys files.

Two read-only commands (run as root) help you see where you stand:

grep "Accepted password for" /var/log/messages
awk -F: '$2=="*" {print $1}' /etc/shadow

The first lists password logins; the second lists the accounts that have * in their password field. Any overlap between the two lists is a red flag. If you forward logs to a SIEM, run the same search there – an attacker with root could have edited local logs. Paste suspicious log lines into our IOC extractor to pull out source IP addresses for blocking; it runs entirely in your browser.

If you can't rule out an unauthorised login, Alpine's advice is to treat the machine as compromised. In practice that means rebuilding it from a clean image and rotating any credentials and keys it held.

What to do

1. Find every Alpine system running sshd. Include containers that run an SSH server and cloud VMs built from Alpine images.
2. Upgrade openssh (apk upgrade openssh). Alpine's fixed versions:

Alpine notes that 3.21 reached end of support on 1 November 2026 but still got a fix, as did the older branches. Plan an upgrade to a supported release anyway.

3. Restart sshd. The package upgrade doesn't replace the running daemon (rc-service sshd restart). For containers, rebuild the image from the updated base and redeploy.
4. If you can't upgrade right away, turn off password logins. Alpine recommends a drop-in file in /etc/ssh/sshd_config.d/ with the line below. Make sure the main sshd_config doesn't override it, then restart sshd. Test key-based login first and keep an existing session open so you don't lock yourself out.

PasswordAuthentication no

5. Run the compromise checks above, especially on machines exposed to the internet since before 5 November.
6. Restrict SSH access. An SSH port shouldn't be open to the whole internet unless it has to be. Allow it only from known ranges or over a VPN – our subnet calculator helps you get the CIDR range for a firewall rule right. This is general good practice, not vendor guidance.
7. Report incidents. If you find an unauthorised login at an organisation, report it to your national CERT – in the UK the NCSC, in the US CISA.

Timeline

Updates

• 13 November 2026 – one-week review: as of 13 November GreyNoise counts 42 post-exploitation chains from 10 addresses, the latest on 12 November. For the first time, one attacker left persistent access behind (a program and services posing as tiny-cloud, plus its own SSH keys) – paths and SHA-256 hashes added under How to tell if you were compromised. NVD completed its analysis on 10 November without adding its own CVSS score. OpenSSH and Alpine have not changed their advisories.
• 10 November 2026 – the flaw is being exploited: CISA added it to the KEV catalog on 9 November (federal deadline 12 November), and GreyNoise saw the first successful attack on 7 November and published attacker addresses and the C2 domain (added under How to tell if you were compromised). Medcrypt reproduced it on a Yocto image used for embedded devices. Added the at-a-glance box.
• 8 November 2026 – first version of this article.