Security researchers say a critical vulnerability in the OpenSSH suite is now being exploited in the wild, less than a week after it became public — a timeline that is turning early warnings about mass Linux compromise into an operational reality.

The flaw, which has circulated under the stylized name *sshole and is more commonly written as SSHole, arises from the interaction between OpenSSH and the musl C standard library, a lightweight libc widely used in Alpine Linux, container base images, and embedded and network devices. Systems that combine both packages and meet certain other conditions can be forced to grant unauthenticated access to high-privilege accounts in a matter of seconds.

Exploitation Confirmed Within Days

According to Ars Technica, the vulnerability became publicly known last Thursday and immediately stoked fears of widespread compromise across Linux estates. By Monday — just four days later — the prediction showed signs of becoming real.

Security firm GreyNoise said honeypots it maintains in Southeast Asia came under attack by a group it tracks as GT10. Notably, GreyNoise described the activity not as opportunistic scanning but as “mature intrusions” into the monitored systems, which the firm uses to detect attempted or successful attacks in real time. GreyNoise subsequently obtained access to a GT10 server, turning the tables on the operators and revealing potential additional victims along with some of the tooling used in the campaign.

The group conducted “mature intrusions” into the systems, which GreyNoise uses to detect attempted or successful attacks in real time.

One detail is likely to draw scrutiny from attribution analysts: a backdoor used in the attacks contains Chinese-language comments and appears to have been generated with the help of AI. Researchers have repeatedly cautioned that language artifacts in malware are weak indicators — tooling, source-code reuse and infrastructure are frequently shared, borrowed or deliberately planted to mislead — but the AI-assisted development angle underscores how quickly lower-skilled actors can now assemble functional implants.

Why Password-Disabled Accounts Don't Save You

Coverage of the bug across security outlets has emphasized different aspects of the same technical story. BleepingComputer framed the issue around a particularly uncomfortable property: the OpenSSH flaw lets attackers log into Linux accounts whose passwords have been disabled. That detail matters enormously, because disabling password authentication and relying on key-based or certificate-based access has long been a standard hardening step for internet-facing SSH.

The practical consequence is that a large share of organizations that believed they had removed the most obvious SSH attack path may still be exposed. The weakness lies in the interaction between the SSH daemon and musl's handling of certain authentication paths, meaning the fix is not a configuration tweak teams can script overnight but a software update — one that must reach container base images, firmware, and appliances that are rarely patched on a weekly cadence.

A Bad Week for Remote Access

The SSHole exploitation is not unfolding in isolation. The Hacker News, whose coverage of the Linux beat has tracked the story alongside Ars Technica, has also reported on unpatched Tailscale SSH flaws that could let a single compromised device reach root on other servers within a mesh network. Separately, Help Net Security reported that attackers are exploiting RouterOS vulnerabilities to hijack MikroTik devices without authentication.

Taken together, the three stories describe a broad and uncomfortable pattern for defenders: the remote-access layer — SSH daemons, mesh VPN overlays, and router management planes — is simultaneously under scrutiny from researchers and under fire from attackers. These are precisely the components that hold the highest privileges and sit closest to the perimeter, and they are frequently the least visible to asset inventories.

• OpenSSH + musl (SSHole): unauthenticated high-privilege access in seconds; exploitation observed within four days of disclosure.
• Tailscale SSH: unpatched flaws could allow a single hacked node to escalate to root on other servers in the tailnet.
• MikroTik RouterOS: flaws exploited to hijack devices without authentication, extending the same pattern to network infrastructure.

What Defenders Should Do Now

Security teams should treat exposure of SSH to the public internet as the immediate priority. Practical steps include inventorying which systems run musl-based distributions or container images with OpenSSH enabled, applying vendor patches or mitigations as they land, and restricting SSH reachability to management networks or zero-trust brokers rather than the open internet. Because the flaw bypasses password-disabled accounts, key-only authentication should be treated as a mitigation for other risks, not a fix for this one.

Detection is equally important. GreyNoise's honeypot-derived intelligence suggests deliberate, hands-on operators rather than automated worms, meaning post-compromise activity — new authorized keys, unexpected service accounts, outbound connections from servers that should not be making them — may be the most reliable signal. Organizations running internet-exposed Linux should audit authentication logs, rotate credentials and keys on any host with unexplained access, and hunt for the backdoor artifacts described by researchers.

The broader lesson echoes previous inflection points in open-source infrastructure security: a bug in a near-universally deployed component, combined with slow patch propagation through containers and embedded devices, creates a window that attackers are now clearly willing to exploit. The question for many organizations is no longer whether SSHole will be used against them, but whether their inventory and patching pipelines can move faster than GT10.