Attackers are exploiting the recently disclosed SSHole vulnerability to gain unauthorised access to vulnerable Linux systems, with security researchers documenting successful intrusions, reconnaissance and attempts to establish persistent access.
Tracked as CVE-2026-123158, the authentication bypass affects specific OpenSSH deployments on Linux systems using the musl C library without Pluggable Authentication Modules, or PAM. Under the required conditions, attackers can access accounts intended to reject password logins without knowing a valid password or possessing an authorised SSH key. The vulnerability carries a CVSS score of 8.1.
The emerging attacks have increased the urgency of installing available updates. Previdian’s vulnerability tracker records 20 exploitation attempts from 13 source IP addresses across nine countries between November 6 and November 8. Separately, GreyNoise has documented successful exploitation of deliberately vulnerable sensors and subsequent attacker activity. These observations establish that the threat has progressed beyond a publicly demonstrated weakness.
A password error that becomes a successful login
SSHole arises from an interaction between OpenSSH’s password verification logic and the way musl handles errors during password hashing.
Linux accounts can have an asterisk, *, in their password field instead of a usable password hash. That value is supposed to prevent password authentication while allowing other permitted access methods, such as SSH keys.
According to researcher Özgün Kültekin’s technical disclosure, the vulnerable authentication path can borrow a salt from another account when the target account lacks a usable hash. Musl’s SHA-based password hashing rejects inputs exceeding its length limit and returns an asterisk as an error indicator.
OpenSSH can then compare that error value with the target account’s stored asterisk and incorrectly accept the match. The resulting access does not require password cracking: the failure occurs because an error response is treated as successful authentication. Kültekin traces the relevant OpenSSH behaviour to a 2016 change intended to address username enumeration through timing differences.
OpenSSH’s release notice describes version 10.6p2 as containing a critical security workaround. Its maintainers consider the underlying cause to sit outside sshd, but acknowledge that the issue is exploitable through the daemon and can be prevented there.
Which systems are exposed?
The vulnerability does not affect every Linux server running OpenSSH. Exploitation depends on a combination of software, authentication settings and account configuration.
Safe Security’s analysis identifies the principal requirements:
A successful attack initially gives the intruder the permissions of the compromised account. Administrative access depends on that account’s privileges and the system’s configuration. Service accounts can nevertheless expose application secrets, deployment credentials and access to connected infrastructure.
OpenSSH’s urgent release announcement states that non-Linux systems, Linux systems using glibc, and systems using PAM for password authentication are outside the scope of this vulnerability. This makes configuration-aware assessment essential: an OpenSSH inventory alone cannot establish which machines are exploitable.
Close security gaps before they lead to costly incidents. Give your SOC the threat visibility to detect and respond earlier👇🏻
Alpine cloud deployments require particular attention
Alpine Linux’s advisory highlights a potentially serious route to administrative compromise in its tiny-cloud images.
Affected images contain an alpine account with an asterisk password field and passwordless doas privileges. They are not automatically exploitable on first boot. Adding a compatible password hash elsewhere on the machine can, however, create the conditions for unauthorised access to that account and subsequent elevation to root.
Direct root login is a separate question. The default PermitRootLogin prohibit-password setting protects root from this password-based route, although it does not prevent a compromised non-root account from exercising existing administrative privileges.
Alpine also states that containers without a running SSH daemon are unaffected by this attack path. Merely using an Alpine container image does not establish exposure.
For infrastructure teams, the operational implication is that exposure can change after deployment. Reviews should therefore examine running instances and their current account state, alongside the templates from which they were created.
Researchers observe reconnaissance and persistence attempts
GreyNoise’s live investigation describes an activity cluster it calls GT10, involving the deployment of a Python runtime and a tool named TAC Agent. Observed artefacts include the agent file and a startup-service entry.
Another intrusion involved checks for containerisation, queries to cloud metadata services and attempts to read sensitive authentication material. These actions illustrate how an SSH foothold can become a starting point for investigating the wider environment.
There are limits to the findings. GreyNoise says TAC Agent failed to enrol with its command-and-control service on the observed victim and received no task. Its suggestion that missing-tool feedback could support an automated command planner is explicitly an inference, rather than proof of autonomous AI operation.
The company also cautions that some associated infrastructure may itself be compromised. An IP address’s location, or the language used in software, does not by itself establish who directed an intrusion.
Large SSH scan counts do not equal confirmed compromises
Internet-wide SSH traffic requires careful interpretation. Port scans show interest in reachable services; they do not establish that a particular exploit was attempted, succeeded or affected a production organisation.
SSH encryption also makes it difficult to identify the authentication bypass solely through passive network inspection. Researchers with instrumented vulnerable systems can obtain stronger evidence by observing authenticated command execution.
Previdian’s published figures are explicitly measurements from its own sensors. They should not be read as a global count of affected organisations, and the countries associated with source addresses do not establish attacker nationality. Its timeline places the first observed attempts shortly after disclosure, illustrating the narrow interval available to defenders once technical details became public.
Patching requires checking the distribution package
OpenSSH released the upstream workaround in 10.6p2 on November 5. Administrators should also check their distribution’s security packages because fixes can be backported to older OpenSSH branches.
Orca Security’s assessment lists the following patched Alpine packages:
The running SSH daemon must be restarted after updating. Installing a corrected package alone does not replace the process already serving connections.
Where immediate patching is not possible, disabling password authentication with PasswordAuthentication no blocks this route. Orca also recommends investigating successful password authentication for accounts that should have no usable password.
Alpine advises administrators to verify that key-based access works and retain their current session while testing a new connection before completing authentication changes.
Exposed systems need an intrusion review
For organisations that operated an affected, reachable service, remediation should include checking whether access occurred before the fix.
A practical investigation should correlate successful SSH sessions with account permissions, process execution, file changes and outbound connections. Unexpected authorised keys, new startup entries or unexplained administrative activity warrant further examination. Where compromise is established, closing the original vulnerability does not remove attacker-created access or invalidate credentials already obtained.
These are incident-response implications of the observed activity, rather than evidence that every exposed server has been breached. The distinction matters when deciding whether a system needs routine remediation, deeper forensic investigation or rebuilding.
Security leaders should prioritise assets by both exploitability and consequence: a reachable deployment account with access to production secrets can present a substantial risk even when direct root authentication is blocked.
A rapidly shrinking response window
The episode also reflects OpenSSH’s changing approach to vulnerability release timing.
In its release notes, the project says it has seen security issues identified through AI tools subsequently rediscovered independently. Maintainers argue that adversaries may possess similar discovery capabilities and say they will release fixes more frequently rather than waiting to batch them into scheduled updates.
That statement concerns the speed of vulnerability discovery; it does not establish that the observed SSHole intrusions were AI-directed.
For defenders, the immediate task is concrete: identify the specific vulnerable configurations, deploy the appropriate corrected package, restart the daemon and investigate suspicious access. SSHole demonstrates how a seemingly protective account setting can fail when authentication components interpret the same value differently—and how quickly a disclosed weakness can become an operational intrusion risk.
Black Friday: Save up to 20% with code BF20OFF at checkout 👇🏻
Click Here For The Original Source.
——————————————————–
