Research

SSHole Now Has a CVE and an Exploitation Report: CVE-2026-123158, a Password Over 256 Bytes Logs In to Alpine Accounts With No Password. One Vendor Saw Root on a Honeypot Nine Hours After Disclosure.

SSHole Now Has a CVE and an Exploitation Report: CVE-2026-123158, a Password Over 256 Bytes Logs In to Alpine Accounts With No Password. One Vendor Saw Root on a Honeypot Nine Hours After Disclosure.

If you run Alpine Linux with sshd, patch to OpenSSH 10.6p2 or turn off password logins today, and then check your logs for logins that should not exist. This is an update to our earlier post on this flaw. That post said no CVE had been assigned and no attacks had been reported. Both of those statements are now out of date.

Timeline and facts for SSHole, CVE-2026-123158. Left: what changed since the first report. A CVE was assigned, the name SSHole appeared, the score is 8.1, and the fix is OpenSSH 10.6p2. Previdian reports eight attempts from one IP within nine hours of the CVE publication, plus root access on an Alpine honeypot; two other outlets say in-the-wild exploitation is not established. Right: what to do. Upgrade, or set PasswordAuthentication no, then search for Accepted password for lines on accounts that have no password. One indicator, 89.116.89.18, is now in our feed at confidence 65, cited from Previdian and not our own sighting.

What changed

The flaw now has an identifier, a name and a score. It is CVE-2026-123158, nicknamed SSHole, and it is rated CVSS 8.1. It affects OpenSSH on Linux systems that use the musl C library and do not use PAM, which includes Alpine's default sshd setup. The fix is OpenSSH 10.6p2. The researcher credited is Özgün Kültekin.

The mechanism, as reported: a 2016 patch for an older bug made a failed password-hashing step return a lone asterisk. Accounts with no password are also stored as an asterisk. Send a password between 257 and 1,024 bytes long, the hashing step fails, the two asterisks compare equal, and sshd lets you in. Key-only accounts are the usual target.

The exploitation report

The Hacker News reports that the threat intelligence firm Previdian saw the first exploitation attempt less than nine hours after the CVE was published. Previdian counted eight attempts from a single IP address, which VirusTotal also places in Japan. Previdian says the source used oversized passwords to get past authentication, then ran id, uname and hostname through non-interactive SSH sessions. Previdian also says it confirmed successful root access on a honeypot running Alpine and OpenSSH.

Not everyone agrees. Safe Security says confirmed in-the-wild exploitation had not been established as of November 6, and GBHackers says none had been reported. Those outlets may simply have published before Previdian did. We treat the exploitation claim as one vendor's observation, reported by a news site, and we are attributing it to Previdian.

Our own evidence

We have none of our own. Our exploit harvester picked up two public proof-of-concept repositories for this CVE, and it emitted no detection rules from them. We have no edge or honeypot sighting of this flaw. Everything about exploitation in this post comes from Previdian through The Hacker News.

The indicator

The reported source address is 89.116.89.18. We added it to the feed at confidence 65, with the source cited, and we read the record back after writing it. That score is below the 80 our own edge shield needs before it blocks anything, and above the 50 default floor of the IP feed, so it ships to default subscribers and is not blocked at our edge. Two cautions. VirusTotal lists it under Nearoute Limited in Japan, with 2 of 92 engines marking it suspicious. OTX shows the same address under IPXO, a company that leases IP space, so the holder of the address can change. Treat it as one scanner seen once, not as infrastructure to build a case on.

What to do now

  • Update and restart. On Alpine, the earlier report gave apk upgrade -U -a followed by rc-service sshd restart. The fixed point releases it named are 3.21.10, 3.22.8, 3.23.8 and 3.24.4.
  • Or turn passwords off. Set PasswordAuthentication no in the sshd config, check it with sshd -t, restart sshd, and confirm with sshd -T. Keep an existing session open until you have confirmed that key login works.
  • Look for logins that should not exist. Alpine's guidance, as reported, is to search /var/log/messages for sshd lines reading "Accepted password for" an account that has no password. Then review doas use, recently created users and files, and authorized keys. If you cannot rule a login out, treat the machine as compromised.
  • Check other musl systems. Embedded builds based on OpenWrt, Buildroot or Yocto are worth a look. Dropbear, glibc-based Linux, non-Linux systems and anything that checks passwords through PAM are reported as not affected.

Limits

This post rests on one secondary source, The Hacker News, plus search results from other outlets. We did not read the OpenSSH, Alpine or Previdian advisories ourselves, we did not test the flaw, and we did not check any system. The score, versions, commands and log paths are as reported. We have not independently confirmed the exploitation, and the address could be a rented or shared one.

Five percent of this is wrong somewhere. It always is. The advisory text will correct a version number or a detail about which builds are exposed.


Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register