SSHole OpenSSH flaw exploited in the wild, with a Chinese-language implant among the payloads

Exploitation of the OpenSSH bug nicknamed SSHole is now happening in the wild, not just in labs. BleepingComputer reported on November 9, 2026 that multiple security firms have confirmed attacks, with attempts starting November 5, the day a proof-of-concept exploit appeared, and successful exploitation recorded the next day.

The flaw was disclosed by researcher Ozgun Kultekin. OpenSSH maintainers fixed it in version 10.6p2, released November 5. Exploit code showed up roughly four hours after that release.

What the bug actually does

The affected setup is narrow but not rare: sshd on Linux using musl libc without PAM. Alpine Linux, common in cloud and container images, is the example everyone cites.

The bypass works against accounts whose password hash in /etc/shadow is set to an asterisk, the usual way of disabling password logins while keeping the account. Send an oversized password, and musl's password-hashing function returns * on error. OpenSSH then compares that error return against the stored * and treats it as a match. The CNA description puts the successful password length at between 256 and 1024 characters.

Kultekin's own caveats matter. Exploitation needs specific authentication settings, and accounts with real password hashes aren't affected. Where the account has passwordless administrative privileges, the login lands as root.

What the attackers did once inside

GreyNoise recorded the first successful exploitation on November 7 at 00:46 UTC, about 40 hours after the fix. Its sensors logged 16 successful exploitation chains from six source IP addresses, and the company is explicit that this isn't representative of the wider activity.

In those chains, the actor ran system and container reconnaissance, queried cloud metadata services, tried to read password hashes and root SSH keys, and edited authorized_keys for persistence. One attacker got root and installed TAC Agent, a Python command-and-control implant. It couldn't reach its server at tac.vpnla[.]org and never received a task. The payload supports shell command execution, file upload and download, reconnaissance, and self-updates. It has no built-in persistence, so the attackers tried to wire it into a startup service.

GreyNoise notes the implant's comments, logs and errors were in Chinese, which it says may be used alongside other evidence to judge origin. It also flags a missing tool check that returns feedback useful to an automated planner, a hint at automated operation.

Other firms saw the same thing at smaller scale. Previdian reported 20 attempts from 13 IP addresses in nine countries. watchTower said on November 6 it saw SSHole used in botnet and cryptomining activity. Defused described "a small amount of actors" trying it, not a broad campaign.

The background noise is large: GreyNoise counted 27.5 million port-22 scans and 20.1 million attempted SSH sessions, none of which are confirmed SSHole attacks.

HackZoneLabs assessment

The interesting part here isn't the CVSS score, it's the shape of the bug. A disabled password is supposed to be a closed door, and on these systems it was a door that opened if you pushed hard enough. That's why the affected population is smaller than "all OpenSSH" but more exposed than it looks: Alpine images are everywhere in cloud and container fleets, and accounts with * in the shadow file are exactly the ones admins assumed nobody could log into.

We'd treat the reported exploitation numbers as a floor, not a measure. Six source IP addresses and 16 chains from one sensor network tell you the technique works and someone is using it. They don't tell you how many hosts were hit, and nobody has published that figure. The failed implant is a useful detail too: it suggests at least one operator is still tuning tooling, which is not the same as saying the campaign is unsophisticated.

The Chinese-language strings in the implant are a lead, not an attribution. GreyNoise says as much.

What to check, and what's still unknown

Patch to 10.6p2. If you can't yet, disable SSH password authentication on affected hosts, which the reporting recommends.

Then look for the traces the attacks leave: successful password logins to accounts whose /etc/shadow password field is *, SSH keys you didn't add, and TAC Agent files or startup services.

Still open: how many systems were compromised, whether the same actor is behind the botnet and cryptomining reports, and whether any of the 20.1 million attempted sessions were SSHole rather than ordinary scanning. The advisory doesn't say, and neither does anyone else yet.

CVE references

CVE-2026-123158