As reported by The Hacker News, threat actors began exploiting CVE-2026-123158 — codenamed SSHole — less than nine hours after its CVE publication, achieving root access on an Alpine Linux honeypot. The speed from disclosure to weaponization is notable but not surprising for an SSH authentication bypass. This is exactly the class of vulnerability that botnet operators and initial access brokers scramble to exploit because it provides a direct, reliable foothold on internet-facing infrastructure.
Why This Vulnerability Is Uniquely Dangerous
The root cause is a decade-old behavioral quirk. A 2016 patch for CVE-2016-6210 altered how OpenSSH handles password hashing. Under specific conditions — musl C library, PAM disabled, and an account whose password field contains an asterisk — an oversized password (257–1,024 bytes) causes the hash operation to fail and return the literal character *. The sshd daemon then compares that returned value against the * stored in the account's password field, interpreting a failed hash as a successful authentication match.
This is not a logic flaw in encryption or a memory corruption issue — it is a semantic mismatch in how a failed operation is interpreted by the authentication pipeline. That makes it extremely difficult to detect with traditional signature-based tools.
The affected surface is narrow but operationally significant:
| Attribute | Detail |
|---|---|
| CVE | CVE-2026-123158 |
| CVSS | 8.1 (High) |
| Affected Software | OpenSSH on musl C library with PAM disabled |
| Primary At-Risk OS | Alpine Linux (default OpenSSH server config) |
| Patch Available | OpenSSH 10.6p2 |
| Active Exploitation | Confirmed — first attempt within 9 hours of disclosure |
| Exploit Vector | Oversized password (257–1,024 bytes) against *-disabled accounts |
The Alpine Linux Exposure Problem
Alpine Linux is the Linux distribution of choice for containerized workloads due to its minimal footprint — it powers a significant percentage of Docker base images. Its default OpenSSH server configuration ships without PAM, relying on musl's libc password handling. This means any Alpine-based container or appliance exposing SSH on a network boundary is potentially vulnerable if it retains default or password-disabled accounts. Embedded devices, IoT firmware, and cloud appliances built on Alpine are particularly exposed because they frequently include service accounts with disabled passwords that were never intended to be interactive login targets.
Who Is Most at Risk
Shield53 Recommendations
- Patch immediately: Upgrade to OpenSSH 10.6p2 on all musl-based systems. This is the only complete fix.
- Inventory password-disabled accounts: Audit
/etc/shadowfor entries with*in the password field. Remove or lock any unnecessary accounts usingusermod -Lorpasswd -l. - Enable PAM where feasible: If your deployment supports it, enabling PAM-based authentication eliminates the vulnerable code path entirely.
- Restrict SSH exposure: SSH should not be internet-facing without VPN or bastion host mediation. Apply network-level controls to limit access to trusted IP ranges.
- Deploy oversized-password detection: Add SSH logging or host-based IDS rules that flag authentication attempts with passwords exceeding 256 bytes — this is anomalous and should never appear in legitimate traffic.
- Hunt for prior compromise: Review SSH auth logs for oversized password attempts and unexpected logins to service accounts. The observed attacker IP (89.116.89[.]18) should be blocked, but assume broader scanning is underway.
The nine-hour window from disclosure to exploitation underscores a reality defenders must internalize: for high-impact, easily automatable vulnerabilities, the patching window is effectively zero. Your incident response plan must assume that internet-facing services are being probed within hours, not days. Prioritize accordingly.
