Threat actors began trying the OpenSSH SSHole flaw, CVE-2026-123158, less than nine hours after disclosure, according to reporting published on 6 November 2026. Previdian confirmed a root login on its own Alpine Linux honeypot running Alpine's default sshd. The CVSS score is 8.1. Exposure is limited to OpenSSH on musl with PAM disabled and an account whose password field is a single asterisk, so a generic OpenSSH version match will alert the wrong set of hosts.
Key takeaways
- CVE-2026-123158 (SSHole, CVSS 8.1) allows an unauthenticated login only where the password field is *, and only on musl OpenSSH with PAM disabled, including Alpine's default sshd.
- Previdian saw the first attempt in under nine hours, in reporting dated 6 November 2026: eight tries from one IP, root on its Alpine honeypot, then id, uname, and hostname.
- glibc distributions, Dropbear, non-Linux systems, PAM password checks, and accounts with real password hashes are out of scope. A ! lock prefix is not the asterisk this bug matches. OpenSSH 10.6p2 or the distro package, plus an sshd restart, is the named fix. The reporting does not list earlier affected releases.
- On Alpine, an Accepted password line for an alpine account, root, or any key-only user is the detection signal. If that login cannot be ruled out, Alpine's advisory says treat the machine as compromised.
Which sshd builds can the OpenSSH SSHole flaw actually log into?
The OpenSSH SSHole flaw, CVE-2026-123158, allows an unauthenticated login only to accounts whose stored password field is a single asterisk, and only on OpenSSH built against the musl C library with Pluggable Authentication Modules disabled. Alpine Linux’s default OpenSSH server configuration is in that set.
Ubuntu, Debian, and other glibc distributions are outside that set. Dropbear is outside it. Non-Linux systems are outside it. Any sshd that checks passwords through PAM is outside it. Accounts that hold a real password hash stay protected.
In the shadow file, a lone asterisk marks a password disabled at the system level. Normal password-crypt output is not supposed to equal it, so password authentication should fail on every attempt. Public-key authentication can still succeed on the same account. A leading exclamation mark is the usual lock prefix, and it is a different string. The reporting describes SSHole as a comparison against the asterisk, not a bypass of a field that only starts with !.
When hashing fails, OpenSSH produces an asterisk. sshd compares that failure output with the asterisk stored on the account and treats the match as a successful login. The attacker does not need a stolen password or an SSH key. The session runs with that account’s existing permissions. Root is the result only when that account is root.
Safe Security stated that a successful SSHole attack grants access with the compromised account’s existing permissions. Unauthorized SSH is the immediate impact. A foothold can also reach deployment credentials, application secrets, and connected infrastructure.
The reporting names OpenSSH 10.6p2 as the fix and says distributions are expected to ship their own patched packages. It does not state which earlier OpenSSH releases are affected. A version below 10.6p2 does not, by itself, prove a vendor build is still vulnerable, because distributors backport fixes without adopting the full upstream release. A banner that reads 10.6p2 is a poor substitute for the Alpine package changelog. Exploitation still needs a reachable sshd, the affected build, password authentication enabled, and at least one qualifying account.
Why did a 2016 hardening patch make a disabled password look valid?
The faulty comparison comes from a 2016 OpenSSH patch written to close CVE-2016-6210, a timing-based username-enumeration bug. The patch added dummy password work so responses for invalid users and valid users would be harder to distinguish. Under the conditions this bug hits, a failed hash and a disabled password look the same to sshd.
When password hashing fails, OpenSSH produces an asterisk. That is the same marker stored for an account whose password is disabled at the system level. sshd compares the two values and treats the login as a success. Ozgun Kultekin is credited with the discovery. The fix shipped in OpenSSH 10.6p2.
The published trigger is an arbitrary password between 257 and 1,024 bytes long. Report that length as the condition the advisory disclosed, and use it as a clue when you review authentication logs. It does not belong in a scanner payload. Reproduction detail stays with the OpenSSH and Alpine advisories.
That comparison has been in the password path since the 2016 hardening change. Disclosure coverage is dated 6 November 2026, and the reporting does not give the exact minute the CVE record appeared. A queue that labels every OpenSSH item “OpenSSH, CVSS 8.1, patch everything” will spend the week on glibc fleets this bug cannot reach and under-test Alpine edges, where a version diff against 10.6p2 often does not flag the host that still needs the distro package.
What did nine hours of honeypot traffic actually prove?
The Hacker News, in a 6 November 2026 report by Ravie Lakshmanan, said exploitation attempts started less than nine hours after the CVE went public. Previdian recorded eight attempts, all from a single source IP geolocated to Japan, and confirmed successful root access on its own honeypot running Alpine Linux and OpenSSH. Eight attempts from one address show rapid probing of a listening sshd. They do not show eight compromised organizations. A Japan geolocation is not an attribution.
No threat group, campaign, or malware family is named in the reporting. Previdian published the source address. It is not repeated here. Pull the indicator from Previdian’s own report if you are building a block list.
Ryan Dewhurst, Previdian’s founder and CEO, told The Hacker News that the source used oversized passwords to bypass authentication. The same sessions then ran reconnaissance through non-interactive SSH: id, uname, and hostname. The honeypot telemetry does not show a miner, a webshell, or a named malware family. Root on that honeypot is the account that was reachable there. The bug does not add a separate privilege-escalation step.
The sub-nine-hour figure measures time to the first observed attempt, not population-wide exploitation. The story is dated 6 November 2026. It does not give an exact CVE publication timestamp, and it does not say whether OpenSSH 10.6p2 landed before or after the CVE record.
What should an Accepted password line mean on a key-only Alpine host?
Alpine’s detection guidance is to look for an sshd log line that should be impossible. Search /var/log/messages for lines reading Accepted password for an account that has no password. Alpine’s examples are an alpine account, root, or any key-only user. A successful public-key line is a different event. Alpine’s advisory says that if you cannot rule the login out, treat the machine as compromised. The review named with that advice covers doas use, plus recently created users, files, and authorized keys on exposed machines.
The commands Previdian saw were id, uname, and hostname. Those commands do not leave an obvious file. The advisory names /var/log/messages. Confirm where sshd output actually lands, whether that is the local file, a container log driver, or a remote collector, before you record that no accepts were found.
PasswordAuthentication no closes this password-verification route and leaves public-key login available. Setting PubkeyAuthentication to yes does not turn password authentication off. KbdInteractiveAuthentication is a separate switch. Read the running config, not the file you assume is authoritative. PermitRootLogin no, or prohibit-password, closes root’s password path and leaves every other qualifying account untouched.
Preserve logs and session evidence before cleanup that would erase them. Then inspect authorized_keys, new users, doas rules, whether doas ran, startup files, and outbound connections. Install OpenSSH 10.6p2 or the distribution’s patched package, then restart sshd. On Alpine, run apk info on the openssh packages and compare the installed version with the fixed package Alpine published. A package install that skips the restart leaves the old sshd in memory.
Beyond the advisory text, review sessions that authenticated before the restart, then repeat the Accepted password search. If you still cannot rule the login out, Alpine’s advisory says treat the machine as compromised.
Why will a version scanner not close this finding?
A version scanner cannot close CVE-2026-123158 from a banner. The reporting gives a fix, OpenSSH 10.6p2, and a build condition rather than a range of vulnerable releases. Marking every package below 10.6p2 hits glibc estates this bug cannot reach, and it can miss a backported Alpine package whose version string never reads 10.6p2.
Four checks beat the banner. Is sshd listening where an attacker or a peer workload can reach it? Is the binary linked to musl, with libpam absent from that linkage? Does the effective configuration run without PAM and with password authentication enabled? Is there at least one account whose password field is exactly an asterisk? The OS name and the OpenSSH version string are context, not the verdict.
| Fact | In scope for SSHole | Out of scope |
|---|---|---|
| Listener | Reachable sshd | sshd not running |
| Linkage | musl, libpam absent | glibc, or PAM linked in |
| Effective config | usepam no, password auth yes | PasswordAuthentication no, or PAM password checks |
| Account | Password field exactly * | Real hash, empty field, or a ! lock prefix |
On Alpine, inventory the packages the distro ships and confirm them against Alpine’s advisory. ldd on the sshd binary shows musl versus libpam. sshd -T prints the effective values for usepam, passwordauthentication, kbdinteractiveauthentication, permitrootlogin, and pubkeyauthentication. Match blocks still need a separate read, because that dump is not every user and source address.
Read qualifying accounts as root. They include an alpine account, root, and any key-only user whose field is the asterisk. An empty field, a real hash, and the asterisk are three different cases. A leading ! locks the account in the usual shadow sense and is not the marker this bug matches.
The reporting states that 10.6p2 fixes the bug. It does not say which earlier OpenSSH releases, or which Alpine package versions, are vulnerable. Until OpenSSH or Alpine publish that list, track the vendor changelog instead of a guessed minimum version. The same lesson showed up in Alpine upgrades that left the vulnerable component in place: a package bump is not proof the affected binary was replaced.
What should a pentest scope add for Alpine base images and appliances?
Add accounts with a disabled password to the test scope even when the ticket says SSH is key-only. The accounts that fail a normal password spray are exactly the ones this logic bug can reach. A test that only tries common short passwords will report SSH as clean and never exercise the disabled-password asterisk.
Scope listeners, not the image registry. Base images, appliance operating systems, and edge hosts that run Alpine’s default sshd are the population to check. A node with no sshd, with PasswordAuthentication no, or with PAM performing password checks is out of scope for this CVE even when the node is Alpine.
Write that condition into the rules of engagement so vulnerability management and the pentest do not file contradictory findings. Map every account whose password field is an asterisk, confirm that password authentication is effective, and attach the account’s real privileges to any accepted password. Then follow what the account can read: deploy keys, cloud roles, doas, and adjacent hosts. Safe Security’s note on deployment credentials describes that impact chain.
If the estate is mostly glibc SSH with PAM, say so in the report. Spend the remaining time on CI runners, network appliances, Kubernetes nodes that still expose sshd for break-glass, and vendor images that never appear in the Linux fleet inventory. That residue is where a fast-moving attacker lands, because version-only scanners never alerted anyone about those hosts. An external network penetration test shows whether that sshd answers from the perimeter. A container security assessment covers the image, the runtime identity, and the accounts whose password field is the asterisk.
FAQ
What is the OpenSSH SSHole vulnerability?
SSHole is CVE-2026-123158, a CVSS 8.1 logic bug in OpenSSH on musl with PAM disabled: a failed password hash yields the same asterisk stored for a disabled password, so sshd accepts a login to that account with no stolen credential or key. Ozgun Kultekin found it, and OpenSSH 10.6p2 fixes it.
Is Alpine Linux affected by CVE-2026-123158?
Alpine's default OpenSSH server configuration matches the affected build: musl with PAM disabled. The host still needs a reachable sshd, password authentication enabled, and at least one account whose password field is *.
Does SSHole affect Ubuntu or Debian OpenSSH?
No. glibc-based Linux distributions are out of scope, as are systems that authenticate passwords through PAM. Ubuntu and Debian fall on that side of the boundary. Dropbear and non-Linux systems are also unaffected.
What OpenSSH version fixes SSHole?
Upstream OpenSSH 10.6p2 contains the fix. Distros are expected to ship their own patched packages, often as backports that do not use the 10.6p2 version string. The reporting does not list which earlier releases are affected, so confirm Alpine's advisory, including the apk package version, before you score a banner.
agent::offense tests Alpine sshd the way this bug actually works: musl linkage, effective password authentication, and every account whose shadow field is a disabled-password asterisk. Where those hosts face the internet, an external network penetration test shows which listeners answer.