Hackers are already exploiting *sshole, an OpenSSH flaw hitting musl-based Linux systems

Attackers are using a newly disclosed flaw in OpenSSH to break into privileged accounts on some Linux systems without credentials, several security firms say. The bug, nicknamed *sshole, affects machines that pair OpenSSH with the musl code library, and it can give an attacker high-privilege access within seconds. OpenSSH has released a fix that stops the attack.

The flaw became public on Thursday, Nov. 5. Researchers at watchTowr said the next day that they were already seeing exploitation, tied to botnets and cryptocurrency. On Monday, Greynoise said a group it tracks as GT10 had attacked honeypots it runs in Southeast Asia. Previdian reported that its sensors had logged 20 exploitation attempts from 13 distinct IP addresses, geolocated to nine countries. The reports don't say whether any of this activity is connected.

One day between disclosure and reported exploitation is a very short window. Administrators who planned to patch on a normal monthly schedule were behind almost from the start. That speed fits the bug's profile: it needs no stolen password, no phishing and no help from a user on the target machine.

The Greynoise findings give the most detailed view of a campaign so far. The firm described GT10's break-ins as "mature intrusions" and said it later got into a GT10 server that pointed to other possible victims and to some of the group's tools. The group's backdoor, which Greynoise tracks as TAC Agent, contains comments written in Chinese and appears to have been built with help from AI, the firm said. TAC Agent can run shell commands, survey a compromised system and keep its foothold there. Because it needs Python 3 to run, GT10 installs that package on machines that lack it.

That last detail gives defenders something concrete to check. Many musl-based systems are stripped down on purpose, so Python 3 appearing on a server where nobody installed it is a change worth investigating.

How the flaw works

The vulnerability, tracked as CVE-2026-123158, only works when several conditions line up. OpenSSH has to be running alongside musl, a lightweight alternative to the more common C library on Linux. OpenSSH must also be running without PAM, the pluggable authentication modules framework that many distributions use to check logins and account access. The system needs at least one account that logs in with a password hashed with SHA256 or SHA512, plus accounts marked as passwordless with an asterisk in the password field of the /etc/shadow file. Passwordless entries of that kind are standard for some types of accounts.

The attack itself is simple. An attacker targets one of those passwordless accounts and submits a password longer than 256 characters. When the server hashes that input to compare it with the stored value, the oversized password causes musl's hashing function to fail and return an asterisk. That output matches the asterisk already in /etc/shadow, so the check passes. Red Hat described the root cause as a "misinterpretation of whether a string is intended to be a password hash."

It's a familiar kind of bug. An error marker gets read as real data, and neither component looks clearly broken on its own. The failure comes from how OpenSSH and musl handle the same character, which helps explain why it could sit unnoticed and why the fix landed in OpenSSH.

Who is exposed

The list of conditions sounds narrow, but it describes a large number of real machines. Systems running Alpine, a small Linux distribution built on musl, face the greatest risk. Alpine is a common base for container images and for small, purpose-built servers, so many teams may be running it without thinking of it as a separate operating system.

Finding targets is also easy. Millions of SSH servers are reachable from the internet, and the flaw lets attackers send commands to them and pick out likely vulnerable ones in seconds. That combination of cheap scanning and a working exploit is why the early warnings about widespread compromise were taken seriously.

The first step is plain: anyone running OpenSSH should install the patched release. Systems that use musl need a closer look, including a check of whether OpenSSH runs without PAM and which accounts carry asterisk entries in /etc/shadow. For container users, patching the host is not enough. Images built on vulnerable versions will keep shipping the flaw until they are rebuilt. And given that reported exploitation began a day after disclosure, any exposed machine that went unpatched over the past several days should be checked for signs of intrusion, not just updated.