An attacker reached root, the all-powerful administrator account, on Previdian's Alpine Linux honeypot. The security firm's founder told Help Net Security about the successful intrusion in a November 6 report on the OpenSSH flaw nicknamed SSHole. A honeypot is a machine used to observe attacks. This was a demonstrated break-in there, not a count of compromised businesses.
The flaw, CVE-2026-123158, affects particular Linux configurations where OpenSSH can accept a password for an account that has no usable password set. Those include some accounts intended for SSH keys. The fix arrived November 5; today's attack reporting makes finding the exposed systems a job for today.
I'd be uneasy with a quick answer of 'we only use keys.' That can describe how the people log in, without describing what the server will accept. An SSH key is a sensible way to authenticate. It doesn't, by itself, mean the password route has been switched off.
The server gets a vote
Alpine's advisory narrows the problem considerably. The affected setup uses musl, a Linux system library, with OpenSSH password checking outside PAM, another authentication component. Password authentication must be enabled, and the machine must have a particular combination of accounts with and without password hashes. These conditions matter. An Alpine container that doesn't run an SSH server isn't affected by this flaw.
The researcher also distinguishes these systems from glibc-based distributions such as Debian and Ubuntu, and from the separate Dropbear SSH server. A business can own Linux systems and have no affected machine. It can also have one tucked inside a cloud application or appliance whose operating system never came up in the purchase conversation.
For example, a small company might leave a hosted application in a developer's care and think of access as 'the developer's key.' In that situation, the useful answer comes from the person who can inspect the actual service and its configuration. A familiar login habit is a poor substitute for that look.
Installed isn't running
For an affected Alpine system, the distribution's instruction is to update OpenSSH and restart the SSH service. It explicitly warns that the package upgrade alone leaves the old service running. Alpine lists fixed package versions for individual release branches, so a backported fix may carry an older-looking version number. The running service and the distribution's advisory belong in the same conversation.
I would give that targeted work priority over a blanket 'update every Linux box' scramble. Have the responsible administrator identify affected, reachable services, apply the supported fix and check suspicious authentication activity. An update closes a vulnerability; it doesn't settle whether someone used it beforehand. Previdian's public sensor record reports attempts and separately cautions that an observed attempt alone doesn't prove a successful compromise.
If the repair involves changing password access, source restrictions or credentials, keep the original working administrative session open. Establish a separate fresh session from each required authorized source with the intended credentials, verify the source address the target sees when restrictions matter, and confirm the necessary administrative privileges. Report any path left untested. A failed check calls for correction or a safe rollback while the original session remains open.
That fresh login checks continued access. Verifying the fixed service is running and reviewing signs of intrusion are separate jobs. I'd want all three answers before calling this finished: the repair took, the administrator can still get in, and someone looked at what happened before the repair.
Sources and further reading
