Exploited in the wildHIGHCISA KEV

OpenSSH 'SSHole' musl bypass gives shell on no-password accounts; exploited, in CISA KEV

CISA added the musl-only sshd password bypass to KEV on 2026-11-09, and honeypot intrusions show C2 agents being installed. Upgrade openssh and restart sshd, or set PasswordAuthentication no. Federal due date: 2026-11-12.

OpenSSH project (OpenBSD); Alpine Linux OpenSSH Portable sshd (musl libc, no PAM)CVE-2026-123158CVSS8.1CWE-394Remote access
Published Nov 6, 2026 · Updated Nov 9, 2026

CISA added the CVE to KEV on 2026-11-09, citing active exploitation 1. GreyNoise and Previdian report successful logins on honeypots, including root access and C2 agent installs 8,11. No production compromise has been publicly confirmed.

Nov 4, 20265 daysNov 9, 2026

What you need to know

  • Exposure: sshd on Linux built with musl libc and no PAM, with password authentication on. This is chiefly Alpine's default openssh-server. Glibc distros, PAM setups, Dropbear and OpenBSD are not affected.
  • Impact: an unauthenticated remote shell, in one connection, as any account whose password field is '*'. On Alpine tiny-cloud images, the alpine user's passwordless doas turns this into root.
  • Exploitation: in CISA KEV since 2026-11-09, due 2026-11-12. Honeypot intrusions since 2026-11-06 include root access, cloud metadata queries and a Python C2 agent.
  • Fix: OpenSSH 10.6p2 or Alpine's patched packages, then restart sshd. The fallback is PasswordAuthentication no, confirmed with sshd -T.
  • Hunt: 'Accepted password for' lines naming a '*' account, new authorized_keys entries, /opt/py3/tac_agent.py, /etc/init.d/tac-agent, and HTTPS to tac.vpnla.org.

What's happening

CVE-2026-123158, nicknamed SSHole, lets an unauthenticated remote attacker log in over SSH as an account that is meant to have no password 3,4. It applies only to Linux hosts where sshd runs on musl libc without PAM 4. OpenSSH 10.6p2, released 2026-11-05, works around the problem inside sshd. The OpenSSH project places the root cause outside sshd 4. Alpine Linux's default openssh-server package is the main exposure. Alpine shipped fixed packages for branches 3.16 through edge the same day 3. Red Hat says its builds link OpenSSH against glibc with PAM and are not affected 5. Horizon3 lists OpenWrt, Buildroot, Yocto, other embedded devices and some Docker images that run sshd as in scope 10. No fix advisories from those platforms were found.

CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-11-09, based on evidence of active exploitation 1,2. Federal agencies must act by 2026-11-12 1,2. The entry lists ransomware use as unknown and requires forensic triage under BOD 26-04 1. Previdian reported its first attempt less than nine hours after CVE publication and confirmed a root login on an Alpine honeypot 11,15. Its later telemetry counts 20 attempts from 13 IPs in 9 countries, seen from 2026-11-06 to 2026-11-08 12. watchTowr links the activity so far to botnets and cryptomining 13. Defused describes a small number of actors and says the activity is not widespread 13. No vendor, government or IR firm has attributed the activity to a named actor.

GreyNoise recorded its first successful exploitation of a deliberately vulnerable sensor at 00:46 UTC on 2026-11-07 8. Attackers ran reconnaissance and checked whether they were in a container 8. They queried the AWS, Azure and Alibaba cloud metadata services and tried to read /etc/shadow and root's SSH keys through doas 8. In one intrusion the attacker gained root and installed a Python C2 agent that GreyNoise calls TAC Agent 8. The agent failed to enroll because the sensor could not reach its C2 8. By its 2026-11-08 update, GreyNoise counted 7 intrusions from 6 attacker IPs 8. Public reports describe successful logins only on honeypots and research sensors 8,12.

Public exploit code appeared on GitHub about four hours after the 10.6p2 release, and GreyNoise calls exploitation trivial 8. BSI warned on 2026-11-06 that a PoC is public 6. Previdian cautions that the PoCs posted on GitHub are unverified and may contain malware 11.

How it works

When PAM is not used, sshd hashes the password attempt with crypt() and compares the result to the account's stored password field 3. musl's crypt() returns * as an error value when the supplied password is too long 3. Accounts with no password also store * in that field. The comparison therefore matches and the login succeeds 3. CISA and the CNA classify the weakness as CWE-394, unexpected return value 1,7.

The bug is reachable because of a defence against user enumeration (CVE-2016-6210) added in 2016 9. When an account's stored field is too short to hold a salt, sshd borrows the salt from another account's hash 3. As a result, one local $5$ or $6$ hash makes every * account reachable 3. The researcher traces the behaviour to musl crypt() design choices from 2012 and to that 2016 OpenSSH change. He says the flaw has existed since about 2016 9. OpenSSH 10.6p2 works around the problem inside sshd; the project places the root cause outside sshd 4. Accounts with a valid password hash cannot be bypassed this way 14.

The attacker needs network reach to sshd, one connection and the name of an account with a * field 3. No credentials or retries are needed 3. Password authentication must be enabled, which is the OpenSSH default 3. sshd must run without PAM: Alpine's default openssh-server, or openssh-server-pam with UsePAM no 3. Typical * accounts are key-only users, directory users served via musl-nscd, root on Alpine since about 3.16, and the alpine user on tiny-cloud images 3. The default PermitRootLogin prohibit-password blocks direct root login 3. Root is still reachable through any account that can escalate, such as one with passwordless doas 3.

Alpine lists these as not affected: containers that do not run sshd, PasswordAuthentication no, accounts locked with !, hosts with no $-style hash, cloud-init images that disable password login, and openssh-server-pam with UsePAM yes 3. Tiny-cloud images 3.18.11 through 3.24.3 are safe on first boot 3. They become exploitable once any $6$ hash exists on the host, for example after a console password is set 3.

What to do

In order of priority
  1. 1

    Upgrade openssh. On Alpine, run apk upgrade -U -a to reach the fixed package for your branch. Elsewhere, install OpenSSH 10.6p2 or your distribution's patched package 3,4.

  2. 2

    Restart sshd after upgrading, on Alpine with rc-service sshd restart. The running daemon keeps the vulnerable code until it restarts 3.

  3. 3

    If you cannot update, set PasswordAuthentication no, including inside Match blocks, and restart sshd 3. Confirm with sshd -T that it reports passwordauthentication no 3. Test key login first and keep the current session open 3. Releases before 3.19 ignore the sshd_config.d drop-in 3.

  4. 4

    On Alpine, openssh-server-pam with UsePAM yes avoids the issue. So does locking accounts with ! instead of * 3. Damien Miller of OpenSSH urged operators of musl systems without PAM to disable password authentication or SSH immediately 11. Where SSH is not needed, turn it off or restrict it to management networks.

  5. 5

    For containers, rebuild images that run sshd with a fixed package and redeploy. Running containers are not fixed by an image update 6. For cloud images, update openssh or disable password authentication on every running tiny-cloud instance built before 3.21.10, 3.22.8, 3.23.8 or 3.24.4 3.

  6. 6

    Federal agencies must remediate by 2026-11-12. KEV requires forensic triage under BOD 26-04, before or alongside patching, and CISA encourages all organizations to follow it 1,2.

  7. 7

    If a password login to a no-password account cannot be ruled out, treat the host as compromised 3. Rotate deployment credentials and application secrets reachable from it; Previdian warns they enable lateral movement 15. Attackers queried cloud metadata services, so review instance-role credentials and activity too 8.

Detection

  • On Alpine, search /var/log/messages for sshd Accepted password for lines naming an account with no password, such as alpine, root or any key-only user 3.
  • Confirm a suspicious login by checking the account's /etc/shadow field, for example with grep '^alpine:' /etc/shadow 14. A successful password login for an account whose field is * indicates the bug was used.
  • Look for post-exploitation changes. Check for new or modified authorized_keys for alpine and root, edits to /etc/hosts and /etc/resolv.conf, doas use, and recently created users or files 3,8.
  • Hunt for the TAC agent artefacts: a Python agent under /opt/py3/, an /etc/init.d/tac-agent init script, ~/.config/tac/agent.json, and outbound HTTPS from Python to tac.vpnla.org with User-Agent TAC-Agent/1.0 8.
  • Review SSH sessions that run id, uname, hostname or /etc/os-release reads right after login. Also look for container checks or requests to cloud metadata endpoints. GreyNoise and Previdian observed these patterns 8,11.
  • Search auth and firewall logs for the attacker IPs listed below. GreyNoise publishes further IPs and hashes on its event page 8. Some sources are shared cloud addresses, so treat matches as leads, not proof.
  • Inventory exposure. Look for musl-built sshd with PAM disabled and password authentication on, where an account with a * field sits alongside a $5$ or $6$ hash 3. Include OpenWrt, Buildroot, Yocto, embedded devices and Docker images that run sshd 10.
  • Do not judge exposure by upstream version alone. Alpine backported the fix under older version numbers, such as 9.9_p2-r1 on 3.21 3,7.

Indicators

As published by the cited sources
TypeValueContext
ip20.255.63.133GreyNoise: exploited a sensor on 2026-11-07, gained root, installed TAC agent. Shared Microsoft cloud IP (AS8075, Hong Kong).8
ip209.248.50.17GreyNoise: 2026-11-07 intrusion that created the tac-agent init script (SAKURA, Singapore).8
ip183.220.91.15GreyNoise: recon, cloud metadata queries, attempts to read /etc/shadow via doas (China Mobile).8
ip89.116.89.18Previdian, via Help Net Security: oversized-password logins and recon on an Alpine honeypot; Japan-geolocated.11
domaintac.vpnla.orgC2 for the TAC agent dropped after exploitation; the agent code describes it as a Cloudflare Worker, per GreyNoise.8
file path/opt/py3/tac_agent.pyPython C2 agent dropped after exploitation.8
sha25655e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2atac_agent.py, 89,559 bytes, version 0.1.1.8
file path/etc/init.d/tac-agentInit script created by an attacker on a GreyNoise sensor.8
sha2567cf69bd6573a90d7bd287810b5c3746841cee6a7f77cadd016f34a97fc7b2361/etc/init.d/tac-agent as dropped, 308 bytes.8
user agentTAC-Agent/1.0User-Agent of the TAC agent's HTTPS C2 traffic.8
file path~/.config/tac/agent.jsonConfig file the TAC agent writes after enrollment.8

Timeline

  1. OpenSSH fix committed privately, about 21:18 UTC. 8

  2. OpenSSH 10.6p2 released with an sshd workaround, about 09:01 UTC. 4

  3. Alpine Linux publishes its advisory and fixed openssh packages for branches 3.16 through edge. 3

  4. Researcher write-up published about 12:19 UTC; first public exploit appears on GitHub about 13:16 UTC. 8

  5. CVE-2026-123158 published about 15:46 UTC; CVSS 8.1, CWE-394. 7

  6. BSI warns that proof-of-concept code is public. 6

  7. Previdian reports first in-the-wild attempts, including a root login on an Alpine honeypot. 11

  8. watchTowr reports exploitation tied to botnets and cryptomining. 13

  9. GreyNoise records first successful exploitation of a sensor at 00:46 UTC, followed by C2 agent installs. 8

  10. End of Previdian's reported window: 20 attempts from 13 IPs in 9 countries. 12

  11. CISA adds CVE-2026-123158 to KEV with a 2026-11-12 due date. 1

  12. Brief updated: status raised from poc_public to exploited after the KEV addition; GreyNoise intrusion data and IOCs added.

Sources

  1. 1
    CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-123158
    CISA · Government · Nov 9, 2026
  2. 2
    CISA Adds Four Known Exploited Vulnerabilities to Catalog
    CISA · Government · Nov 9, 2026
  3. 3
    Security advisory: openssh-server password authentication bypass
    Alpine Linux · Vendor · Nov 5, 2026
  4. 4
    OpenSSH Release Notes (10.6p2)
    OpenSSH project · Vendor · Nov 5, 2026
  5. 5
    CVE-2026-123158 - Red Hat Customer Portal
    Red Hat · Vendor
  6. 6
    OpenSSH: Schwachstelle gefährdet Alpine Linux und weitere Produkte
    BSI (Germany) · Government · Nov 6, 2026
  7. 7
    CVE-2026-123158 CVE record
    CVE Program (cvelistV5) · Database · Nov 6, 2026
  8. 8
    SSHole (CVE-2026-123158) Activity 2026
    GreyNoise · Research · Nov 8, 2026
  9. 9
    *sshole
    Özgün Kültekin (Wakefield), discoverer · Research · Nov 5, 2026
  10. 10
    CVE-2026-123158: OpenSSH musl Bypass (*sshole)
    Horizon3.ai · Research · Nov 6, 2026
  11. 11
    OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)
    Help Net Security · News · Nov 6, 2026
  12. 12
    Hackers Exploiting 'SSHole' Authentication Bypass in OpenSSH
    SecurityWeek · News
  13. 13
    Hackers exploit SSHole OpenSSH flaw to breach Linux systems
    BleepingComputer · News
  14. 14
    OpenSSH flaw lets attackers log into password-disabled Linux accounts
    BleepingComputer · News · Nov 5, 2026
  15. 15
    Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
    The Hacker News · News · Nov 6, 2026

Corroborated by independent sources. Researched and drafted by the VulnDigest briefs agent from 15 sources, then checked against them by a separate review step on Nov 9, 2026.

Exploitation rests on CISA KEV plus independent reports from GreyNoise, Previdian, watchTowr and Defused. The OpenSSH and Alpine advisories predate the activity and do not state exploitation. Successful logins are reported only on honeypots and sensors.

First-activity dates differ by sensor. BleepingComputer says attempts began 2026-11-05, Previdian 2026-11-06, and GreyNoise's first success was 2026-11-07 00:46 UTC. first_seen uses Previdian's date.

Previdian's own page and watchTowr's post could not be checked directly. Their figures come via Help Net Security, SecurityWeek, The Hacker News and BleepingComputer.

CWE differs: CISA KEV and the CNA give CWE-394, Red Hat gives CWE-303.

The IOC list is partial. GreyNoise also lists 20.2.81.241, 47.80.65.43, 79.116.138.30 and more file hashes. GreyNoise labels its TAC agent analysis as LLM-generated and subject to update.

No exposure count was found, and no actor is attributed. Fix status for non-Alpine musl platforms (OpenWrt, Buildroot, Yocto) is unknown.

Spotted an error? Open an issue on sochub.io.