SSHole Exploited Within Hours: Attackers Got Root on an Alpine Honeypot

It took less than nine hours. Threat intelligence firm Previdian says attackers began exploiting “SSHole”, the OpenSSH password bypass on Alpine and other musl-based Linux, within hours of its CVE going public, and got root on one of its Alpine honeypots. The Hacker News reports the first source, an IP geolocated to Japan, made eight attempts and ran basic reconnaissance once inside. Previdian’s tracker now counts 17 attempts from 11 IPs in eight countries. We explained the bug on Thursday; it is now in active use.

89.116.89[.]18 (first observed SSHole exploitation, per Previdian)

Source article: Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot
Publisher: The Hacker News (Ravie Lakshmanan)
Published: Nov. 6, 2026
URL: https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html

Executive Summary

Attackers began exploiting CVE-2026-123158, the OpenSSH authentication bypass named SSHole (also written *sshole or sshhole), less than nine hours after the CVE was published, according to Previdian, which confirmed successful root access on an Alpine Linux honeypot. The flaw affects sshd before OpenSSH 10.6p2 on Linux systems built against the musl C library without PAM, including Alpine’s default openssh-server package: when an account’s password field is too short to hold a salt, sshd hashes the attempt with another account’s salt, musl’s crypt() returns * for any key over 256 bytes, and that matches the * stored for accounts with no password, so a password of 257 to 1,024 bytes logs in. Alpine says exploitation needs PasswordAuthentication yes, an account whose password field is * (key-only users, directory users through musl-nscd, root when PermitRootLogin yes, or the alpine user in tiny-cloud images, which has passwordless doas), and at least one local account with a $5$ or $6$ hash. No actor has been named; the first source, 89.116.89[.]18, made eight attempts, used oversized passwords to log in and ran id, uname and hostname over non-interactive SSH sessions, and Previdian’s tracker shows 17 attempts from 11 IPs in eight countries by Nov. 7. Public proof-of-concept and scanner repositories exist. The objective so far is opportunistic access to exposed Linux servers, appliances and cloud images, with the account’s existing privileges and a short path to root where doas or root login is allowed. Hunt leads, false positive expectations and indicators are detailed below; no detection rules or file hashes have been published.

ATT&CK chain: Initial Access → Discovery → Privilege Escalation → Persistence

Hunt Lead Grid

Accepted Password for an Account With No Password

The bug turns a “no password” account into one that accepts any password of 257 to 1,024 bytes, and sshd records the result the normal way: an Accepted password for <user> from <ip> line. Alpine’s own guidance is to look in /var/log/messages for those lines naming an account that has no password, such as alpine, root or any key-only user. The first observed attacker, 89.116.89[.]18, made eight attempts, and Previdian has since seen 17 attempts from 11 addresses in Switzerland, Denmark, Iran, Japan, the Netherlands, Norway, Singapore and the US. The detection logic is to build, for every musl-based host running sshd, the list of accounts whose /etc/shadow field is * (plus directory users served through musl-nscd, which have no shadow entry), then alert on any “Accepted password” event for those accounts, and sweep all SSH logs for 89.116.89[.]18.

Use syslog from Alpine hosts (/var/log/messages, or whatever the host forwards), central log collection, and firewall or NetFlow records for SSH connections from the listed address. Sweep back to Nov. 5, 2026, the advisory date, and further if you have it, since the bug dates to a 2016 change. Scope first to internet-facing Alpine, OpenWrt and other musl systems, Alpine tiny-cloud instances from 3.18.11 through 3.24.3, and containers that run sshd. There is no legitimate way to produce this event, so do not tune it; the false positive risk is only an incomplete account list. Blocking the one IP is the wrong control, because the source count is already growing; patching or PasswordAuthentication no closes the hole. Any hit means the host is compromised until proven otherwise; Alpine says that if you cannot rule out a login, treat the machine as compromised.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Initial Access → T1133 (External Remote Services); Initial Access → T1078.003 (Valid Accounts: Local Accounts) (our mapping)

Sources: “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot”, The Hacker News, Nov. 6, 2026, https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html (source article); “Security advisory: openssh-server password authentication bypass”, Alpine Linux, Nov. 5, 2026, https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/ (additional source); “CVE-2026-123158 Exploitation Attempts Observed”, Previdian, https://previdian.com/CVE-2026-123158 (additional source)

Password Login Followed by Non-Interactive Recon Commands

Previdian says the first attacker, once logged in with an oversized password, did not open an interactive shell; it ran id, uname and hostname through non-interactive SSH sessions, the pattern of an automated checker confirming access and fingerprinting the box before deciding what to do next. That sequence is a cheap behavioral anchor that does not depend on the attacker’s IP: sshd accepts a password, then spawns a shell that immediately runs a short burst of identity and system-information commands with no TTY, and the session closes. The detection logic joins the sshd authentication event (method password, user, source IP) to process execution under that session: child processes of the sshd session for that user with no allocated terminal whose command lines are id, whoami, uname, hostname or cat /etc/os-release, within about a minute of the login.

Use auditd execve records or an EDR agent on Linux hosts, joined to sshd authentication logs by user, time and session; on Alpine without an agent, auditd with an execve rule for processes whose parent is sshd is enough. Sweep from Nov. 5, 2026. Scope to musl-based hosts first, but the lead also catches automated password-guessing successes on any Linux system. Configuration management, monitoring and backup tools run these commands over SSH constantly, so suppress by their source IP and by key authentication rather than by command; password-authenticated sessions from outside your management ranges are the signal. Blocking uname or id is the wrong approach. A hit on a vulnerable host should be triaged with the first lead and escalated as a compromise.

Hunt Lead Level: 2 (Pro)

ATT&CK: Discovery → T1082 (System Information Discovery); Discovery → T1033 (System Owner/User Discovery) (our mapping)

Sources: “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot”, The Hacker News, Nov. 6, 2026, https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html (source article)

Post-Login doas, New Users and authorized_keys Changes

The account SSHole opens decides what the attacker gets next. Alpine’s tiny-cloud images ship an alpine user with a * password field and passwordless doas, so a login there becomes root with one command; root itself is reachable directly when PermitRootLogin yes is set; and key-only service users may hold deployment credentials and secrets, as Safe Security notes. Alpine’s response guidance names the follow-on artifacts to review: doas use, recently created users, new files, and changes to authorized_keys. The detection logic is a session-scoped correlation: after a password login for an account that should not accept passwords (lead one) or from an unfamiliar source, alert on doas invocations, writes to any ~/.ssh/authorized_keys, edits to /etc/passwd, /etc/shadow or /etc/doas.conf, and new cron entries within the same session or the following hours.

Use auditd watches on /etc/passwd, /etc/shadow, /etc/doas.conf, /etc/doas.d/ and authorized_keys files, syslog for doas (which logs through syslog on Alpine), and file integrity monitoring, correlated with sshd authentication events by user and time. Keep a baseline of which admins use doas and from where for at least 30 days. Sweep from Nov. 5, 2026, and keep watching after patching, because a key or account added before the fix survives it. Patching sshd alone is the wrong end state on a host with a hit; the attacker’s key or user persists, so review and reset authorized_keys, remove unknown users, and rebuild where root was reached. Any correlated hit is an incident. The lead generalizes to any SSH initial-access bug, not just this one.

Hunt Lead Level: 3 (Elite)

ATT&CK: Privilege Escalation → T1548.003 (Abuse Elevation Control Mechanism: Sudo and Sudo Caching) (our mapping; doas is the sudo equivalent on Alpine); Persistence → T1098.004 (Account Manipulation: SSH Authorized Keys); Persistence → T1136.001 (Create Account: Local Account) (our mapping; review steps per Alpine, not observed activity)

Sources: “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot”, The Hacker News, Nov. 6, 2026, https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html (source article); “Security advisory: openssh-server password authentication bypass”, Alpine Linux, Nov. 5, 2026, https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/ (additional source)

Hash Appendix

No file hashes have been published; the exploitation observed so far is a login with an oversized password followed by built-in commands, with no malware files.

References Appendix

• “Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot”, The Hacker News (Ravie Lakshmanan), Nov. 6, 2026, https://thehackernews.com/2026/11/hackers-exploited-openssh-sshole-flaw.html (source article; exploitation timeline, attacker IP, post-login commands)
• “CVE-2026-123158 Exploitation Attempts Observed”, Previdian, https://previdian.com/CVE-2026-123158 (additional source; attempt counts, source countries, KEV status)
• “Security advisory: openssh-server password authentication bypass”, Alpine Linux, Nov. 5, 2026, https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/ (additional source; preconditions, affected images, fixed packages, log checks)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/