SSHole now allows attackers to break into Linux servers running vulnerable OpenSSH configurations: attackers can bypass authentication, execute commands, search for credentials, and try to maintain access. Several security firms have observed attempts and successful exploitation since the first days of November, and GreyNoise recorded a case in which the intruder gained root privileges.
The vulnerability, identified as CVE-2026-123158, affects systems that meet specific conditions, not every OpenSSH installation. The fix arrived with OpenSSH 10.6p2, released on November 5. Administrators who cannot update yet can disable password authentication, although this prevents users who still depend on it from accessing the system.
A flaw linked to musl and accounts with disabled passwords
Security researcher Özgün Kültekin disclosed SSHole last week. The problem lies in how OpenSSH interprets the result of a function in the musl libc library when checking passwords. It can affect distributions such as Alpine Linux, which is also used in cloud and virtualized environments.
Several requirements must coincide for the attack to work: OpenSSH must be running with musl, the check must be performed without PAM, and password authentication must be enabled. In addition, the target account must have an asterisk in the password field of /etc/shadow, and another local account with a valid SHA-crypt hash must exist, according to the description published by RedesZone.
The error is triggered by an exceptionally long password. When it exceeds 256 bytes, musl's password-hashing function can return an asterisk as an error signal. OpenSSH interprets that value as a match for the asterisk stored for the target account and accepts the authentication. Debian Security Tracker describes a range of 256 to 1,024 characters in which some configurations may accept any password; RedesZone puts the documented range at 257 to 1,024 bytes.
The available descriptions differ on these thresholds, but agree on the mechanism and that the vulnerability depends on the configuration. Accounts with valid password hashes cannot be bypassed using this flaw. Kültekin also noted that specific authentication options are required and that access can be escalated to root if the compromised account has passwordless administrative privileges.
GovCERT.HK rated the advisory as a high threat on November 6 and recommended applying the update immediately. Its alert identifies systems running OpenSSH versions earlier than 10.6p2 as affected and describes the impact as a bypass of security restrictions.
The first signs appeared on November 5
Proof-of-concept code was published on November 5, about four hours after OpenSSH maintainers released the patched version. BleepingComputer reports that several firms placed the start of exploitation attempts on the same day, and that some recorded successful access the following day.
Honeypot data collected by Johannes Ullrich, a researcher at the SANS Internet Storm Center, shows a sharp increase in suspicious requests. His Cowrie systems recorded 232 requests with passwords made up of the letter “A” repeated on November 5; the next day, there were 713. These figures count requests, not confirmed attacks or unique actors: the same IP address can make repeated requests.
Ullrich observed activity starting on November 1, but considered the initial attempts to look like misconfigured brute-force scripts, not necessarily deliberate SSHole attacks. Some may have entered download commands in the password field itself. Cowrie stores only the first 255 characters of each input, so it cannot fully inspect longer passwords. Ullrich suspected that a login to one of his honeypots may have succeeded, although his logs did not confirm an open session.
The IP addresses that generated the most attempts in that data were 213.86.169.133, with 48; 152.233.50.185, with 44; and 92.255.57.7, with 43. RedesZone also reported that some sources claimed to have confirmed root access on an Alpine Linux honeypot, citing the CVE in a November 6 post. SANS remained cautious about the extent of exploitation on production servers exposed to the internet.
GreyNoise documented root access and a TAC agent
GreyNoise placed its first observed successful case on the network at 00:46 UTC on November 7, approximately 40 hours after the fix was released. Its researchers counted 16 successful exploitation strings against networks protected by its sensors, originating from six IP addresses associated with post-access activity. The company warned that its observations do not necessarily represent the full scope of attacks related to SSHole.
After gaining access, the attackers performed reconnaissance of the system and containers, queried cloud metadata services, and attempted to read password hashes and root SSH keys. They also tried to modify authorized_keys files to maintain access.
In one incident, an attacker gained root privileges and installed TAC Agent, a Python-based command-and-control agent. The implant failed to connect to its C2 server, tac.vpnla[.]org, and received no tasks. Therefore, although access and installation took place, GreyNoise did not observe the agent executing instructions from that server.
Analysis of the program shows functions for executing shell commands, gathering extensive system information, uploading and downloading files, and updating itself. TAC Agent does not include persistence on its own; in the observed activity, the attackers tried to ensure it would run by configuring a startup service.
The agent's comments, logs, and errors were in Chinese, a clue that GreyNoise says could be combined with other evidence to investigate the attacker's origin. The company also noted that a tool check was missing: the program could return an error that would help an automated planner correct commands and continue the attack. This detail points to a possible automated operation, but does not by itself identify those responsible.
GreyNoise has also counted 27.5 million scans of port 22 and 20.1 million attempted SSH sessions. The company clarifies that these figures are not confirmed SSHole attacks. Separately, Finnish firm Defused said over the weekend that it had seen “a small amount of actors” attempting to exploit the flaw and described the activity as limited.
Previdian, another network security company, also confirmed successful exploitation. Its telemetry data showed 20 attempts from 13 attacker IP addresses spread across nine countries. Offensive security firm watchTower reported attacks associated with botnets and cryptocurrency-mining activity on November 6.
Which systems Debian patched and how to reduce risk
Debian Security Tracker lists the OpenSSH packages included in bookworm, versions 1:9.2p1-2+deb12u10 and 1:9.2p1-2+deb12u9, and in trixie, versions 1:10.0p1-7+deb13u4 and 1:10.0p1-7+deb13u2, as vulnerable. In forky and sid, package 1:10.6p2-1 is listed as fixed. The situation depends on the distribution and installed package; a visible version number does not always reflect a backport, so RedesZone recommends checking the specific package revision.
BleepingComputer and GovCERT.HK's primary recommendation is to update OpenSSH. Alpine had already published fixed packages in its repositories, according to RedesZone, which recommends installing the distribution update and restarting sshd. If immediate patching is not possible, disabling PasswordAuthentication closes this attack vector. Before doing so, check whether any users still need to log in with a password, as they will no longer be able to do so.
It is also advisable to review access logs for successful password logins to accounts whose /etc/shadow field contains an asterisk, as well as for unauthorized SSH keys or files and startup services related to TAC Agent. RedesZone recommends paying particular attention to failed attempts followed by an accepted authentication within the same session.
The fix is available, but observations by GreyNoise, Previdian, and watchTower show that the flaw has moved beyond proof of concept to attempts and access in real-world environments. For systems that cannot yet apply the patch, the immediate question is whether they can temporarily do without SSH password access.
Sources: BleepingComputer, RedesZone, GovCERT.HK, Debian Security Tracker
