The Dumbest Way to Break Into SSH (CVE-2026-123158)

Every once in a while, a critical security vulnerability drops that makes you laugh before you check your fleet. It isn’t a complex cryptographic flaw or an esoteric memory corruption zero-day. It’s an accidental comedy of errors where two completely reasonable safety features collided and accidentally left the front door wide open.

Enter CVE-2026-123158, also known as “SSHHole.”

The Two “Smart” Ideas

To understand how this broke, you only need to know how two separate systems tried to be safe:

1. The Classic Lockout Trick: For decades, Unix systems have disabled password logins on specific accounts by putting a single asterisk (*) in their /etc/shadow file. The idea is simple: no real password ever hashes down to just *. If you can’t generate that string, you can’t log in with a password. It’s the standard way to enforce key-only access or lock a system account.
2. The Defensive Limit: Over in musl libc—the lightweight C library popular on minimal distributions like Alpine Linux—developers wanted to protect against CPU-exhaustion attacks. They capped password length checks at 256 characters. If someone feeds in a password longer than that, it fails immediately. And rather than returning a null value that might crash lazy software, it returns a safe error code: *.

The Facepalm Moment

Picture what happens when someone attempts to log into a locked, key-only account using a random 257-character password:

1. OpenSSH hands the long password to the system to check.
2. The library sees 257 characters, rejects it for being too long, and returns its error string: *.
3. OpenSSH takes that return value (*), looks at the account’s stored password field (*), and sees an exact match.
4. OpenSSH assumes the password is correct and drops the attacker straight into a shell.

* equals *. Access granted.

Who Actually Needs to Worry?

If your servers run Debian, Ubuntu, Fedora, or RHEL, you’re fine. Those distros use glibc, which doesn’t have this behavior.

This flaw lives almost exclusively in the Alpine Linux and embedded world. The crosshairs land on setups where:

• You’re running Alpine or another musl-based distro.
• PasswordAuthentication yes is enabled in sshd_config.
• An account (like a default cloud user or service account) has its password disabled with * under the assumption that keys are required.

On an Alpine cloud VM where the default user has passwordless administrative rights, feeding in 257 characters handed out instant root privileges without needing an SSH key at all.

What to Do

• Update your packages: Upstream patched this immediately by making SSH reject stored hashes shorter than four characters. If you run Alpine boxes, update openssh and bounce the daemon (package managers don’t restart running services for you).
• Hard-disable password auth: Never rely on an account simply “not having a password” as your only defense. Explicitly set PasswordAuthentication no in your /etc/ssh/sshd_config.

Sometimes the scariest vulnerabilities aren’t high-level math—they’re just software accidentally agreeing with itself.