sshole (CVE-2026-123158): Fix OpenSSH on Alpine Now

A critical SSH authentication bypass landed yesterday, and if your Docker containers run on Alpine Linux, you need to act now. CVE-2026-123158, nicknamed “sshole,” lets an attacker log into a locked Alpine account by sending any password longer than 256 characters. CVSS 8.1. The fix shipped the same day as disclosure — but only takes effect after you upgrade and restart sshd.

Patch First, Read Second

If you’re running sshd on Alpine Linux, run this now:

# Check if you're vulnerable
sshd -T | grep -i -E 'passwordauthentication|usepam'
# Safe: "passwordauthentication no" OR "usepam yes"
# Vulnerable: "passwordauthentication yes" AND "usepam no"

# Fix: update and restart (both steps are required)
apk upgrade -U -a
rc-service sshd restart

For Alpine versions older than 3.16, no patched package exists. In that case, your only option is to disable password authentication immediately:

echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
rc-service sshd restart

What About Your Docker Containers?

This is where most developers should focus. Alpine Linux is the most popular Docker base image — it has been pulled over a billion times on Docker Hub, and its 5MB footprint is why it ends up in nearly every microservice stack. The question is not whether your servers are patched. It is whether sshd is running in any of your containers.

In practice, most app containers do not run sshd and are unaffected. However, debug containers, vendor appliances, CI/CD agent images, and anything that exposes SSH for remote access are in the blast radius. Alpine’s official AWS and Azure cloud images are particularly exposed: they ship with a default alpine user whose password field is * (locked, no password) and who has passwordless doas (sudo) access. That combination is a direct path to root on any unpatched system reachable via SSH.

# Check whether a running container has openssh-server installed
docker exec <container> apk info openssh-server 2>/dev/null

# Rebuild affected images to pick up the patch, then redeploy
# Running containers must be restarted — rebuilding the image alone does not update the live process

CVE-2026-123158: How Three Old Decisions Became One Bad Vulnerability

The origin story makes sshole worth understanding, not just patching. Three separate design decisions — each defensible at the time — compounded into a CVSS 8.1 authentication bypass a decade later.

• 2012, musl libc: When crypt() fails, musl returns "*" rather than NULL — intentionally, to prevent crashes in callers that skipped error checks.
• 2012, musl libc: Passwords longer than 256 bytes are rejected, causing crypt() to fail and return "*".
• 2016, OpenSSH (CVE-2016-6210 fix): To prevent user enumeration via timing differences, OpenSSH now runs a fake hash even for locked accounts — borrowing salt from a real account to normalize response time.

The collision: a locked account has "*" as its shadow password field. Send a 257-character password. musl’s crypt() rejects the oversized input and returns "*". OpenSSH compares "*" against "*". They match. You’re in.

Furthermore, the 2016 timing fix — designed specifically to harden OpenSSH against user enumeration — is precisely what enables this bypass. Security hardening created a new attack surface. That is not a reason to skip hardening; it is a reason to audit the interactions between mitigations. This same class of “defense creates vulnerability” dynamic is something we’ve seen in other CVEs this week.

Who Is Affected — and Who Can Relax

The vulnerability requires all four of the following to be true simultaneously:

• sshd compiled against musl libc without PAM (Alpine Linux’s default openssh-server)
• Password authentication enabled (the sshd default)
• A target account with * as its password hash (locked or no-password account)
• At least one other account with a real password hash — to supply the timing salt

Debian, Ubuntu, and Fedora use glibc, not musl, so they are not affected. Additionally, systems with PAM enabled remain protected regardless of OpenSSH version. Dropbear SSH is not affected. If you are not running Alpine, OpenWrt, Buildroot, or Yocto, you can breathe easy.

Security Disclosure Is Changing

Meanwhile, the OpenSSH maintainers disclosed CVE-2026-123158 on the same day the fix shipped — no embargo window. Their reasoning: “AI tools rediscover reported bugs, sometimes within hours.” The traditional 90-day coordinated disclosure model assumes a window where only the discoverer and the vendor know. As a result, that window is now shorter than it used to be, and security teams are adjusting accordingly. BleepingComputer’s analysis covers the disclosure timeline in detail.

TL;DR

• sshole (CVE-2026-123158) lets attackers bypass SSH password authentication on Alpine Linux with any 257+ character password
• Root cause: musl crypt() returns "*" for oversized passwords, colliding with OpenSSH’s 2016 timing attack fix
• Fix on Alpine 3.16+: apk upgrade -U -a && rc-service sshd restart
• Alpine older than 3.16: no patch — disable password auth immediately
• Docker users: audit containers for running sshd; rebuild and redeploy affected images
• Not affected: Debian, Ubuntu, Fedora (glibc), systems with PAM enabled
• Full technical breakdown at Cycode’s Docker-focused analysis and the GitHub security advisory