Hardware Ready Ready to Bench?
OpenSSH SSHole. The flaw bypasses authentication on musl-based Linux systems, such as Alpine, when PAM is not in use. GreyNoise recorded 16 successful exploitation chains and the installation of TAC Agent, a Python-based command-and-control agent.
SSHole, the OpenSSH vulnerability tracked as CVE-2026-123158, is being exploited in real-world attacks. On November 9, CISA added it to the Known Exploited Vulnerabilities (KEV) catalog and requires U.S. federal civilian agencies to apply fixes by November 12.
OpenSSH SSHole: why it matters
The flaw, rated 8.1 on the CVSS scale, allows authentication bypass on musl-based Linux systems—musl being an alternative C library to the more widely used libc—including Alpine, a distribution heavily used in cloud and virtual environments. The issue was made public on November 5 by researcher Ozgun Kultekin. On the same day, OpenSSH maintainers released version 10.6p2 with the fix, and approximately four hours later, a proof-of-concept exploit circulated.
The first exploitation attempts were detected between November 5 and 6. The first successful exploitation recorded by GreyNoise dates back to November 7 UTC, roughly 40 hours after the patch release. Defused, a Finnish security firm, observed a small number of actors attempting to exploit SSHole, noting that activity is not yet widespread.
WatchTowr detected exploitations linked to botnets and cryptomining on November 6. Previdian sensors recorded 20 attempts from 13 IP addresses geolocated in nine countries, data corroborated by other reports citing 22 attempts from 14 addresses.
The list of source addresses made available by GreyNoise begins on November 5 and, starting from the 6th, is largely populated with Amazon addresses declaring Paramiko as the client, a Python SSH library. The list classifies these as malicious or suspicious without indicating which events were successful.
The attack targets accounts whose password field in /etc/shadow contains an asterisk (*), the convention that prevents password-based access, standard for certain account types. When the OpenSSH server receives a password longer than 256 characters for one of these accounts, musl’s hashing function errors out and returns *. OpenSSH interprets this value as a match with the stored account hash and grants access.
Red Hat describes the cause as a “misinterpretation that a string is intended to be a password hash.” OpenSSH must run on musl without PAM, the pluggable authentication modules. The configuration must also include at least one account reachable via a password stored as a SHA256 or SHA512 hash, in addition to passwordless accounts.
According to Kultekin, accounts with valid hashes are not affected, and access can escalate to root if the compromised account has administrative privileges without a password. The pool of exposed machines remains broad, especially among Alpine systems, and identifying vulnerable servers appears to take mere seconds.
GreyNoise recorded 16 successful exploitation chains against networks it protects, a figure confirmed by other reports at 18, with six source addresses linked to post-compromise activity. The company clarifies that these attacks do not represent the full scope of SSHole-related activity.
What changes and what are the effects
Attackers conducted reconnaissance on systems and containers, queried cloud provider metadata services, attempted to read root password hashes and SSH keys, and modified the authorized_keys file to ensure persistent access. Also according to GreyNoise, scans on port 22 amount to 27.5 million, and SSH session attempts to 20.1 million; these figures do not represent confirmed SSHole attacks.
In one instance, the attacker gained root privileges and installed TAC Agent, a Python-based command-and-control (C2) agent. The implant failed to reach its server at tac.vpnla[.]org and never received instructions. Payload analysis shows it can execute shell commands, conduct extensive system reconnaissance, list directories, transfer files in both directions, and self-update. It lacks native persistence mechanisms, which is why attackers attempt to configure a startup service.
GreyNoise also observed the installation of Python3 on machines lacking it, as the agent requires it to run. GreyNoise honeypots maintained in Southeast Asia were targeted by a group the company tracks as GT10, responsible for “mature intrusions.” GreyNoise subsequently gained access to one of the group’s servers, where it found other potential victims and part of the campaign tooling.
Comments, logs, and backdoor errors are in Chinese, an element that, along with others, may help trace the origin of the attacks. The code appears to be generated with AI assistance. Additionally, there is a lack of checks for tool presence that would provide useful feedback to an automated planner for correcting commands, suggesting at least partially automated operations.
Administrators should update OpenSSH as soon as possible or disable SSH password authentication on affected systems; those using musl are advised to verify their exposure. Look for successful password-based logins on accounts with * in the /etc/shadow field, unauthorized SSH keys, TAC Agent files, and startup services created to keep it active.
Source and further reading on OpenSSH SSHole: original article.
* Content created with the assistance of artificial intelligence systems.