"A small amount of actors" tried to exploit SSHole, although activity was not widespread, Finnish security company Defused reported.
CVE-2026-123158 (SSHole): how the bug works
SSHole is a vulnerability in OpenSSH — tracked as CVE-2026-123158 — that allows attackers to bypass authentication on some musl-based Linux systems. The flaw affects OpenSSH when it runs on systems that use the musl C library (including the lightweight Alpine distribution common in cloud and container images) and when accounts have their password field set to an asterisk (*) to explicitly disallow password logins.
The root cause is a mismatch in error handling: an oversized password supplied by an attacker triggers musl’s password-hashing function to return an asterisk (*) on error. OpenSSH then mistakenly treats that returned asterisk as a match for the account’s stored value, allowing a login. According to security researcher Ozgun Kultekin, exploitation requires specific authentication settings and does not affect accounts with valid password hashes; however, when a compromised account has passwordless administrative privileges, the exploit can lead to root access.
Timeline: disclosure, patch, and exploit code
OpenSSH maintainers released a fix in version 10.6p2 on November 5. A proof-of-concept exploit became available that same day, and exploit code appeared roughly four hours after the patch was published. Multiple cybersecurity firms reported that exploitation attempts began on November 5, the day the PoC was released, with some reporting successful exploitation the following day. GreyNoise recorded the first successful exploitation it saw on November 7 at 00:46 UTC, which the company described as occurring approximately 40 hours after the OpenSSH fix.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageObserved intrusions and the TAC Agent implant
Analysts who observed post-exploitation activity describe a consistent pattern. In the attacks logged by GreyNoise, actors performed system and container reconnaissance, queried cloud metadata services, attempted to read password hashes and root SSH keys, and tried to modify SSH authorized_keys files to establish persistence. GreyNoise documented 16 successful exploitation chains tied to six source IP addresses that were subsequently linked to post-exploitation operations.
One attacker achieved root privileges and installed a Python command-and-control implant the researchers label TAC Agent. That implant could not reach its command-and-control endpoint at tac.vpnla[.]org and therefore never received tasks, but analysis of the payload showed features for shell command execution, broad system reconnaissance, file upload/download, and self-updating. TAC Agent contains no built-in persistence mechanism; attackers attempted to compensate by creating startup services to relaunch it. GreyNoise also noted that the implant’s comments, logs, and error messages were in Chinese — a data point that analysts said could be used alongside other evidence when assessing origin.
Telemetry and scale: scans, sessions, and confirmed attempts
The volume of related network activity is large but not all of it is confirmed to be exploitation of SSHole. GreyNoise recorded 27.5 million port-22 scans and 20.1 million attempted SSH sessions in the period it surveyed, while cautioning that those figures are not confirmed SSHole attacks. GreyNoise’s detailed observations included 16 confirmed successful exploitation chains and the single TAC Agent installation described above.
Other telemetry corroborated exploitation in smaller numbers. Sensors operated by Previdian reported 20 attempts from 13 attacker IP addresses across nine countries. Offensive security firm watchTower reported November 6 observations of SSHole exploited in attacks associated with botnets and cryptomining activity. Defused characterized activity over the weekend as involving “a small amount of actors” and not broadly widespread.
What this means for system administrators and cloud operators
The immediate, concrete defenses are the ones OpenSSH maintainers and multiple responders have emphasized: update OpenSSH to version 10.6p2 or later as soon as possible, or disable SSH password authentication on systems affected by SSHole. In addition, teams should audit systems for signs of the post-exploitation behaviors witnessed in the wild: unexpected successful password logins to accounts whose /etc/shadow password field is an asterisk (*), unauthorized additions to SSH authorized_keys, and files or startup services related to TAC Agent.
Because the observed intrusions included attempts to read cloud metadata and container information, cloud-hosted and containerized environments that use musl-based images such as Alpine should receive priority attention.
Open questions remain about the scale and intent of the actors behind confirmed intrusions: GreyNoise’s telemetry shows concrete, limited campaigns and a single documented TAC Agent install that failed to phone home, while other vendors report modest but real exploitation attempts. For defenders, the next step is clear — patch, disable password logins where feasible, and hunt for the specific artifacts and behaviors documented by responders.
