SSHole OpenSSH flaw actively exploited to breach Linux systems

BleepingComputer reports that a newly disclosed OpenSSH vulnerability, tracked as CVE-2026-123158 and nicknamed SSHole, is being actively exploited to execute commands, steal credentials, and establish persistent access on some Linux systems. The flaw affects OpenSSH on certain musl-based distributions, and researchers saw proof-of-concept code and exploitation activity appear within days of the public disclosure.

What the SSHole OpenSSH flaw is and how it works

According to BleepingComputer, the bug arises on systems that use the musl C library for password hashing, including the lightweight Alpine Linux distribution often used in cloud and container environments. On those systems, an oversized password can cause musl's hashing function to return an asterisk character. OpenSSH mistakenly treats that asterisk as the account's stored password hash, which lets an attacker authenticate to an account whose /etc/shadow password field is set to an asterisk, meaning the account is configured to prevent password logins.

The researcher who disclosed the issue explained that exploitation needs specific authentication settings and does not affect accounts that already have valid password hashes. Where the compromised account has passwordless administrative rights, attackers can gain root access, the report says.

Timeline and observed activity

BleepingComputer says OpenSSH maintainers released a fix in version 10.6p2 on November 5, and proof-of-concept exploit code appeared roughly four hours later. The outlet reports that exploitation attempts began on the same day the proof-of-concept became available.

Not all monitoring services saw the same scale. Finnish firm Defused told BleepingComputer it observed what it called, "a small amount of actors" trying to use the flaw. GreyNoise recorded the first confirmed successful exploitation on November 7 at 00:46 UTC, about 40 hours after the fix. GreyNoise logged 16 successful exploitation chains from six source IPs targeting networks that it monitors. Those attacks included system and container reconnaissance, queries to cloud metadata services, attempts to read password hashes and root SSH keys, and modifications to SSH authorized_keys files to try to gain persistence.

Other telemetry in the report includes 27.5 million port-22 scans and 20.1 million attempted SSH sessions seen by GreyNoise, though the company cautioned that those numbers are not all confirmed SSHole attacks. Network security company Previdian reported 20 attempts from 13 attacker IP addresses in nine countries. Offensive security firm watchTower linked some observed exploitation to botnet and cryptomining activity.

What attackers did after they got in

BleepingComputer describes one case where an attacker gained root privileges and installed a Python command-and-control implant called TAC Agent. That implant performed reconnaissance, supported shell command execution, file upload and download, and could update itself, the report says. The implant had no built-in persistence, so attackers tried to make it persistent by creating a startup service. GreyNoise also noted that the implant's comments, logs, and errors were in Chinese, which may help attribution efforts. In this specific case the TAC Agent could not reach its command-and-control server at tac.vpnla[.]org and did not receive tasks.

Practical steps you can take now

BleepingComputer lists immediate actions system administrators should take, and the following is a straightforward checklist for small teams and nonprofit IT staff:

• Update OpenSSH on affected systems to the fixed release as soon as possible, or if you cannot update immediately, disable SSH password authentication.
• Check authentication logs for unexpected successful password logins to accounts whose /etc/shadow password field is an asterisk.
• Inspect authorized_keys files for unauthorized entries and review which accounts have SSH access.
• Search for files or services related to TAC Agent and for any unexpected startup services that might have been added.
• Review accounts with passwordless administrative privileges and remove unnecessary root-equivalent access.

If you run containers or host instances from musl-based images such as minimal Alpine variants in cloud or virtual environments, prioritize those hosts for the checks above.

How we know and what to watch for

The reporting in BleepingComputer is based on telemetry and analysis from several security companies, including GreyNoise, Defused, Previdian, and watchTower. GreyNoise's analysis showed active follow-up steps by attackers after initial access, and other firms reported exploitation attempts tied to cryptomining and botnet activity. As BleepingComputer notes, exploit code was public shortly after the fix, increasing the risk that more actors will try to reuse it.

If you want a quick external check of how exposed your site is, start with a free external scan on our security page: /security.html.

Keep monitoring and maintain good hygiene

Because proof-of-concept code and exploitation attempts appeared quickly after the vulnerability was disclosed, the safest approach is to assume exposed hosts may be probed. Apply the OpenSSH update, disable password-based SSH where practical, and sweep logs and file systems for signs of post-exploitation activity described above. Continue to monitor vendor advisories and your own telemetry for indicators tied to TAC Agent or unusual authorized_keys changes, and treat any confirmed compromises as root-level incidents until shown otherwise.

BleepingComputer is the primary source for the details in this briefing, drawing on telemetry from multiple security companies and the original researcher disclosure.