Facts checked Nov 9, 2026
GreyNoise logged 16 attack chains on its own sensors as of 17:26 UTC Nov. 9; attackers left keys and startup files, so hosts exposed before patching need a persistence check, not only a log search.
What GreyNoise saw
GreyNoise's SSHole tracker counts a success only when sshd ran operating-system commands on one of its own vulnerable sensors. As of 17:26 UTC Nov. 9 it lists 16 such chains since Nov. 5; the first came at 00:46 UTC on Nov. 7. Exploit code had appeared on GitHub on Nov. 5, 2.5 hours before the CVE ID was reserved, GreyNoise said. The tracker also counts 31 million SYN scans of TCP 22 and 5 possible exploitation attempts. Attempts that reached a shell are counted under the 16 instead, which is why that number is larger. CISA added CVE-2026-123158 to its KEV catalog on Nov. 9 and marked forensic triage "Yes".
What the attackers left behind
GreyNoise names three attackers; 7 of the 16 chains are unattributed, including the first and every write to authorized_keys. One cluster it calls GT10 (7 addresses, 2 intrusions) pinned a command-and-control domain, tac[.]vpnla[.]org, in /etc/hosts, dropped a Python agent under /opt/py3 and added an init script so it starts at boot. GreyNoise's LLM-generated analysis says enrollment never succeeded on its sensor. A second attacker, 183[.]220[.]91[.]15, checked for a container, queried AWS, Azure and Alibaba metadata services and tried to read /etc/shadow through doas. It wrote no files. A third, 79[.]116[.]138[.]30, ran discovery and credential-access commands.
Unattributed sessions added keys to authorized_keys for alpine and root on two sensors, with the comments SSHHOLE-HIT and fleet-access. Other changes on the sensors: resolv.conf rewritten, /tmp/apk_repos created, and a second sshd on port 2222 with TCP forwarding. Process data shows a shell under sshd-session in some chains. GreyNoise also lists GT10's exploit-sending addresses (20[.]255[.]63[.]133, 209[.]248[.]50[.]17, 20[.]2[.]81[.]241, 47[.]80[.]65[.]43), plus hashes and client fingerprints. It warns some may be compromised legitimate hosts, and to block the domain, not its shared Cloudflare address.
Who is affected
Alpine hosts and images with sshd, password authentication on and the conditions in Alpine's Nov. 5 advisory; our Nov. 7 piece covers the mechanism and fix. All high-confidence intrusions are on GreyNoise sensors. Its separate medium-confidence list comes from artifacts on an attacker's server covering one shard of its scanning: Australia 13, India 12, New Zealand 9, Japan 7, Hong Kong 5, South Korea 5, Taiwan 5, France 1. That is GreyNoise's list, not confirmed victims. Its lack of a US entry does not clear US hosts. Previdian's page, read Nov. 9, reports attempts only, none on a victim outside its honeypots.
What to do now
- Platform team, today: list every musl host or image whose sshd was reachable with password authentication on since Nov. 5; upgrade and restart sshd on any still unpatched, after a quick snapshot, because Alpine says the upgrade alone does not replace the running daemon.
- System owners, today: on each, check authorized_keys for every account, /etc/init.d and rc-update, /opt and /tmp, /etc/hosts, resolv.conf, listening ports and doas use. Alpine's advisory already says to review doas use and authorized keys; GreyNoise supplies the artifact list.
- SOC, this week: search DNS and proxy logs for the domain and SSH logs for the IPs. GreyNoise said SSH encryption makes attempts hard to see in network traffic, so host checks carry more weight.
- Incident response, on any hit: treat the host as compromised, per Alpine, rebuild it and rotate cloud roles and keys reachable from it. Snapshot first if that is quick: CISA's guidance under BOD 26-04, which binds only federal civilian agencies, says to collect evidence before remediating when possible. Do not leave an exposed host unpatched while you wait.
