While researchers were already aware of limited activity targeting a recently disclosed password authentication bypass vulnerability in OpenSSH, that activity now appears to be accelerating.
“During the past 24 hours, we have observed a small amount of actors targeting SSHole (CVE-2026-123158),” said cyber security firm Defused on X over the weekend.
“Exploitation is not widespread yet, but is showing an early accelerating trend.”
Threat Intelligence firm GreyNoise is also on the case, tracking activity via its dedicated SSHole events site.
“GreyNoise is monitoring scanning, exploitation attempts, and successful exploitation of CVE-2026-123158, also known as ‘SSHole,’ a flaw in OpenSSH on musl-based Linux (such as Alpine) that lets an oversized password authenticate to accounts configured to reject password logins,” the company said.
“Due to the encrypted nature of secure shell (SSH), discerning exploitation attempts strictly through network traffic is challenging. As of 6 November, we have confirmed vulnerable gridpoints deployed. Successful exploitation is being tracked as executing shell commands on the vulnerable system.
“CVE-2026-123158 is trivial to exploit and working exploits are publicly available.”
GreyNoise is tracking several clusters of activity and said the first successful exploitation of a vulnerable GreyNoise gridpoint occurred on 7 November, with the attack originating from a Chinese IP address.
“The attacker checked whether the system ran in a container, queried AWS, Azure and Alibaba Cloud metadata services, and tried to read root’s SSH keys and the password hashes in /etc/shadow through doas,” GreyNoise said.
“The attacker wrote no files and installed no tools.”
The US Cybersecurity and Infrastructure Security Agency added CVE-2026-123158 to its Known Exploited Vulnerabilities Catalog.
What do I need to know?
Ramy Rahman, senior solutions engineer at security governance firm ArmorCode, told Cyber Daily that while the vulnerability itself is narrow in scope and “only works on a particular kind of lightweight Linux setup”, its impact will be far broader. He describes Alpine Linux, which is vulnerable to the flaw, as the “go-to base image for containers and lightweight infrastructure, so a flaw like this can be baked into hundreds of images that teams may have forgotten they’re running”.
“What makes this one fascinating is that it’s a collision of two perfectly reasonable behaviours. One C library returns an asterisk as an error. Meanwhile, accounts with no password, which is what you want for key-only users, store an asterisk to mean ‘no password.’ The error and the stored value match, and the door opens,” Rahman said.
“Nothing here is a classic memory-safety bug. It’s an assumption mismatch between components, and reportedly it sat there for about a decade, in part because this code is mostly tested on one OS and one C library. It’s a reminder that mainstream software can have blind spots when it runs in less-tested environments. It’s also ironic: the accounts that follow best practice are the ones that become the way in.
“Organisations should start with three questions: where are we running OpenSSH on musl, is password authentication enabled, and do we have passwordless accounts?”
Rahman recommends the following remediation steps:
- Patch affected systems: Upgrade to OpenSSH 10.6p2 or the distribution’s fixed package, then restart `sshd` to ensure the running daemon is updated.
- Rebuild container images: Use a patched base image rather than attempting in-place fixes. If an immediate update is not possible, disable password authentication.
- Check exposure: Determine whether `sshd` links against musl and review `/etc/shadow` for accounts marked with `*`.
- Investigate potential compromise: Check `/var/log/messages` for successful password logins by accounts without passwords, and review `doas` activity, new users, files and authorised SSH keys. Treat any host with an unverified login as compromised.
- Restrict SSH access: Apply network-level access controls until systems are patched and ensure password authentication remains disabled for key-only accounts.
Patching, Rahman believes, is simply not enough to tackle this vulnerability.
“Don’t let a ‘not affected’ label on glibc distributions become a blind spot. The question to ask is what’s actually running in your environment, including images and appliances you didn’t build,” he said.
“Treat this as an opportunity to create a process if you don’t have one already. Every few months, a vulnerability like this is likely to land.
“Teams that can respond quickly have a repeatable motion and tools that provide visibility into their own exposure across all scanners, prioritise what matters most, and compress the time it takes from finding to fixing down to hours.”
Want to see more stories from trusted news sources?Make Cyber Daily a preferred news source on Google.
