SSHole: OpenSSH Bypass on Alpine and musl Linux Is Exploited, CISA Deadline Is Today

What happened

OpenSSH 10.6p2 is a one-fix point release that followed 10.6/10.6p1 (October 6). Its release notes describe a "critical security workaround" to "avoid password authentication bypass that is exploitable through sshd(8) that affects some Linux systems when built and run with PAM support disabled." The notes credit Özgün Kültekin of Wakefield with the discovery and add: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there."

The CVE record scores the flaw at CVSS 3.1 8.1 (High), with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H and weakness CWE-394 (Unexpected Status Code or Return Value). Its description reads: "For some configurations of accounts, any password between 256 and 1024 characters succeeds."

CISA lists it as "OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability", added 2026-11-09 with a due date of 2026-11-12, forensic triage marked "Yes" and known ransomware use "Unknown". The required action points to CISA's BOD 26-04, "Prioritizing Security Updates Based on Risk", and its forensics triage requirements. The deadline binds US federal civilian agencies. For everyone else it is a strong signal, not a legal obligation. Three other flaws joined KEV the same day with the same due date: CVE-2026-102895 (GPUStack), CVE-2026-116779 (SignalWire FreeSwitch) and CVE-2026-123218 (IBM Aspera Faspex).

How the bypass works

The bug lives where three old decisions meet. None of them is dangerous on its own.

1. In August 2012, musl capped the key length of its SHA-256 and SHA-512 crypt() at 256 bytes (KEY_MAX) as DoS protection. A longer password makes the hash function fail.
2. Since musl commit b3c4cc12 (also August 2012), crypt() returns the string "*" on failure instead of NULL.
3. In /etc/shadow, a "*" in the password field is the traditional marker for "no password can match". It is how key-only and service accounts are set up.

Put together: an attacker sends a password over 256 bytes, musl's crypt() fails and returns "*", sshd compares that "*" with the "*" stored for the account, sees a match, and lets the attacker in.

The account still needs a salt to hash with, and that is where 2016 comes in. The fix for CVE-2016-6210, a username enumeration bug, made sshd hash passwords even for accounts without a usable hash, borrowing the salt of another account. That behavior also applies to real users whose hash is "*". This is why the attack needs at least one other account on the system with a real password hash.

Alpine supplied the "*" accounts. Since about Alpine 3.16 the base image ships root as "root:*". The change came from a December 2021 patch titled "scripts/genrootfs.sh: locked -> invalid password", whose message says "this still forbids password login but allows logins via ssh keys with pam disabled."

Who is affected and who is not

This is not a bug in every OpenSSH server. All of the following must be true:

• The system uses musl libc (Alpine, OpenWrt, Buildroot, Yocto).
• sshd runs without PAM. This is the default in Alpine's openssh-server package.
• PasswordAuthentication is enabled. It is on by default.
• At least one account has "*" as its password field.
• Another account on the system has a real password hash.

Accounts with a real password hash are not bypassed: the attacker can only log into the "*" accounts. Per the researcher, glibc systems (Ubuntu, Debian, RHEL and the like), systems that use PAM, Dropbear and OpenBSD are not affected.

Alpine's advisory says it found the problem in "every Alpine release we checked, 3.21 through 3.24 and edge", and in the end-of-life releases 3.16 to 3.20. On a stock install, root is shielded by the default PermitRootLogin prohibit-password, but it is reachable if an admin set PermitRootLogin yes. Key-only users and directory-service users (nslcd, winbind, sssd) with "*" are exposed.

Exploitation in the wild

GreyNoise published a minute-by-minute timeline (UTC):

• Nov 5, 09:00 - the fix lands in the public OpenSSH repository; 10.6p2 is announced on oss-security at 09:01.
• Nov 5, 12:19 - the researcher's writeup with the exact trigger goes live.
• Nov 5, 13:16 - the first public exploit appears on GitHub, 2.5 hours before the CVE ID was reserved.
• Nov 5, 15:46 - CVE reserved; published to NVD with CVSS 8.1 at 16:17.
• Nov 7, 00:46 - first successful exploitation, against a GreyNoise sensor.
• Nov 9 - added to CISA KEV.
• Nov 12 - KEV remediation deadline for federal agencies.

As of November 12, GreyNoise counts 38 confirmed successful exploitation chains from 9 attacker IPs since November 5, up from 16 chains and 6 IPs reported on November 9. It also logged 53.3 million SYN scans of TCP port 22 over the same period, but most port-22 traffic is unrelated background noise, and GreyNoise notes that because SSH is encrypted, picking exploit attempts out of the traffic is "challenging". Successful exploitation was seen in countries including New Zealand, Laos, Australia, India, Japan and France.

Other sensors tell a similar story. Previdian lists 30 attempts from 19 unique IPs in 12 countries between November 6 and 11. watchTowr said on November 6 that it saw exploitation tied to botnets and cryptomining, while Defused saw "a small amount of actors" and called the activity not widespread. No threat actor has been named.

The payload: TAC Agent

The successful chains GreyNoise captured dropped "TAC Agent", a single-file Python 3 implant at /opt/py3/tac_agent.py (v0.1.1). It beacons every 150 seconds to tac.vpnla.org with the User-Agent "TAC-Agent/1.0" and can run recon, list, read, exfiltrate and drop files, update itself and run arbitrary shell commands. Attackers also installed a Python runtime, probed cloud metadata services, tried to read /etc/shadow through doas and modified authorized_keys. One victim got an /etc/init.d/tac-agent startup service. GreyNoise says enrollment never succeeded and the agent never received a task.

How to fix it and check for compromise

On Alpine, upgrade and then restart sshd. The advisory is explicit: "Upgrading the package does not restart a running sshd."

apk upgrade -U -a
rc-service sshd restart

Check the package revision, not the version banner. Edge carries openssh 10.6_p2-r0, but stable branches got backported fixes under older version numbers, for example 10.0_p1-r11 on 3.21 and 9.9_p2-r1 on 3.20. A server that reports an OpenSSH version older than 10.6p2 can therefore already be patched, and scanners that read only the banner will flag it.

If you cannot update right away, turn off password logins with a drop-in file and restart sshd:

echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-sshole.conf
rc-service sshd restart

To look for signs of a break-in, compare successful password logins with accounts that should have no password:

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

If an account's password field is "*" but the log shows an accepted password login for it, the box was most likely hit. The researcher's check tool is at github.com/oz9un/sshole. GreyNoise also suggests hunting for ~/.config/tac/agent.json, /opt/py3/tac_agent.py, an /etc/init.d/tac-agent service, unexpected authorized_keys entries and /etc/hosts lines pinning tac.vpnla.org. Block that domain rather than its IP, 104.21.88.83, which is a shared Cloudflare address.

Whose bug is it?

Nobody fully owns this one. OpenSSH patched sshd but says the root cause lies outside it, and the release notes list no CVE number. Write-ups say musl maintainer Rich Felker does not consider it a musl vulnerability. The researcher traces it to musl's 2012 switch from NULL to "*", a return value that POSIX does not call for.

On oss-security, Gentoo developer Michael Orlitzky argued that since nobody knows what crypt(3) will return on error, authenticating logins with a plain strcmp on its output is "optimistic". The OpenSSH fix is commit 4353fdc4 in openssh-portable.

Frequently asked questions

Is my Ubuntu or Debian server affected?

No. Glibc-based distributions are not affected, and neither are systems that run sshd with PAM. The bug needs musl libc.

Does any password work?

No. Only passwords longer than 256 bytes, up to 1,024, trigger the bypass, and only against accounts whose password field is "*". Accounts with a real password hash still require the correct password.

I upgraded the package. Am I safe?

Only after sshd restarts. The running daemon keeps the old code until you run rc-service sshd restart or reboot.

Are Alpine Docker containers at risk?

Only if they run sshd with password authentication enabled and are reachable. Most Alpine containers do not run sshd at all, but those that do and have not restarted it since November 5 should be treated as exposed.

Does the CISA deadline apply to private companies?

No. The November 12 due date binds US federal civilian agencies. For everyone else, a KEV listing means confirmed exploitation and is a reason to prioritize the fix.

Sources

• OpenSSH release notes: https://www.openssh.org/releasenotes.html
• Researcher writeup (Özgün Kültekin): https://sshhole.com/
• Alpine Linux advisory: https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
• GreyNoise live activity report: https://sshole.events.greynoise.io/
• CISA KEV catalog data: https://raw.githubusercontent.com/cisagov/kev-data/main/known_exploited_vulnerabilities.json
• Previdian CVE entry: https://previdian.com/CVE-2026-123158
• BleepingComputer: https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/
• SecurityWeek: https://www.securityweek.com/hackers-exploiting-sshole-authentication-bypass-in-openssh/
• oss-security thread: https://www.openwall.com/lists/oss-security/2026/11/06/2
• OpenSSH fix commit: https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482

Key takeaways

• SSHole (CVE-2026-123158, CVSS 8.1) lets a 257-1024 byte password log into "*" accounts on musl Linux running sshd without PAM.
• Alpine is the main target; glibc distros, PAM setups, Dropbear and OpenBSD are not affected.
• Exploitation is confirmed: 38 successful chains from 9 IPs per GreyNoise as of Nov 12, dropping a Python implant called TAC Agent.
• CISA's KEV deadline for federal agencies is today, Nov 12.
• Fix with apk upgrade -U -a and rc-service sshd restart; the restart is not optional. Otherwise set PasswordAuthentication no.