Events Secure.com at Black Hat USA 2026

Long Password, Open Door: OpenSSH Authentication Bypass Hands Attackers Root on Alpine Linux

Attackers can log in to passwordless Alpine Linux accounts with a long password. Patch OpenSSH 10.6p2, restart sshd and check your logs today.

OpenSSH authentication bypass CVE-2026-123158: musl crypt() returns an asterisk for long passwords, matching locked accounts in /etc/shadow

sshole: The OpenSSH Bug Attackers Exploited Before Lunch

A password that’s too long should fail. On Alpine Linux, it can log an attacker straight in. OpenSSH rushed out an emergency fix this week, and attackers started using the flaw less than nine hours after it went public.

What Happened?

OpenSSH released version 10.6p2 on November 5. Its own release notes call it a critical security workaround. The flaw is tracked as CVE-2026-123158 (CVSS 8.1) and nicknamed “sshole.” It hits sshd on Linux systems built on the musl C library that check passwords without PAM. That’s exactly how Alpine ships its default openssh-server package. OpenWrt, Buildroot and Yocto builds may also be exposed, along with plenty of container images built on Alpine.

How a Long Password Opens the Door

When musl’s crypt() gets a password longer than 256 bytes, it fails and returns a single asterisk. Locked accounts, and accounts meant for SSH keys only, store that same asterisk in /etc/shadow. sshd compares the two, sees a match, and waves the attacker through. Any password between 257 and 1,024 bytes works. The attack also needs password logins switched on and at least one other account with a real password hash. On a default Alpine box, both are common.

CVE-2026-123158 · How it works

One asterisk, two meanings.

On Alpine and other musl systems running sshd without PAM, an error code and a locked account look exactly the same. sshd can’t tell them apart.

01
Attacker sends a huge password
Anything from 257 to 1,024 bytes
02
musl crypt() gives up
Over its 256 byte limit, it returns *
03
Shadow file says * too
Locked and key only accounts store a lone asterisk
04
sshd sees a match
Login accepted. On cloud images, doas leads to root
crypt(long_pw) → *==/etc/shadow → *

OpenSSH 10.6p2 now rejects any stored password field shorter than four characters, so the lone asterisk can never match again.

Already Under Attack

A threat intelligence firm logged its first exploit attempt less than nine hours after the CVE went public. All eight attempts so far came from one IP address. Once inside, the attacker ran basic reconnaissance commands and got confirmed root on a honeypot running real Alpine Linux. Proof-of-concept code is already public on GitHub. CISA hasn’t added the flaw to its KEV catalog yet.

sshole · Disclosure to exploitation

Patch day became attack day.

The fix and the first attacks landed inside the same working day. Teams waiting for the weekly patch window were already behind.

Nov 5 · Morning UTC
OpenSSH ships 10.6p2
Emergency workaround, with a warning to disable password logins now
Nov 5 · Same day
Alpine patches 3.16 to edge
Point releases 3.21.10, 3.22.8, 3.23.8, 3.24.4
Nov 5 · Later
CVE-2026-123158 published
CVSS 8.1. Public repro labs listed in the record
Under 9 hours later
First attacks hit honeypots
Root confirmed on a real Alpine box
<9h
CVE to first exploit
8
Attempts logged
1
Source IP

What’s the Impact?

Anyone who can reach port 22 and knows a valid account name can walk in. On official Alpine cloud images, the default alpine user can often jump to root through doas without a password. From there, attackers can steal data, plant backdoors, and move sideways across your network.

How to Avoid This

  • Patch now. Upgrade to OpenSSH 10.6p2, or to Alpine 3.21.10, 3.22.8, 3.23.8 or 3.24.4. Fixed packages exist for every branch from 3.16 onward, even ones past end of support.
  • Restart sshd. The update doesn’t restart it for you, so the old code keeps running.
  • Can’t patch today? Set PasswordAuthentication no once you’ve confirmed key logins work. Then check Match blocks, which can switch password logins back on.
  • Lock down SSH to office and corporate VPN IP ranges.
  • Hunt for “Accepted password for” log lines tied to root, alpine or accounts that should only use keys. Then review doas use, new users and authorized_keys files. If you can’t rule out access, treat the host as compromised.
Exposure check · Alpine & musl

Five boxes ticked means one open door.

The bypass only works when every condition on the left lines up. Default Alpine images tick most of them out of the box.

You’re exposed if
All five are true
  • 1OpenSSH older than 10.6p2 on musl
  • 2UsePAM no or no PAM package
  • 3PasswordAuthentication yes
  • 4An account with * as its password
  • 5Another account with a real hash
Close it today
Break any one link
  • ✓apk upgrade -U -a to the fixed package
  • ✓Restart sshd so the new code runs
  • ✓PasswordAuthentication no as a stopgap
  • ✓Allow port 22 from VPN and office IPs only
  • ✓Grep logs for Accepted password for

Not affected: glibc distros, sshd with PAM, Dropbear and OpenBSD.

Patching Is the Easy Part. Finding Every Box That Needs It Isn’t.

Bugs like this rarely win because the fix is hard. They win because nobody can say which containers, routers and forgotten cloud images still run Alpine with password logins on.

  • See every internet facing SSH service and the base image behind it, including the ones nobody remembers spinning up
  • Test exposure the way an attacker would, so you know which hosts can actually be reached and exploited
  • Flag risky settings like PasswordAuthentication yes on hosts that should never accept passwords
  • Catch the first password login on an account that has only ever used keys, with full context attached
  • Run patch and restart workflows with human approval built in.

Governed Defense, Powered by Offense. No More Grunt Work. No More Burnout.

Frequently Asked Questions

What is CVE-2026-123158 (sshole)?
CVE-2026-123158, nicknamed sshole, is an OpenSSH authentication bypass rated CVSS 8.1. On musl based Linux systems where sshd checks passwords without PAM, a password longer than 256 bytes can log an attacker in to any account whose stored password is a single asterisk.
Which systems are affected?
Alpine Linux running its default openssh-server package is the main target. OpenWrt, Buildroot and Yocto builds, and container images based on Alpine, may also be exposed. glibc distros, sshd with PAM, Dropbear and OpenBSD are not affected.
Is the OpenSSH authentication bypass being exploited?
Yes. A threat intelligence firm saw its first exploit attempt less than nine hours after the CVE went public, and the attacker got root on an Alpine honeypot. Proof of concept code is public on GitHub.
How do I fix it?
Upgrade to OpenSSH 10.6p2 or to Alpine 3.21.10, 3.22.8, 3.23.8 or 3.24.4, then restart sshd. If you can’t patch today, set PasswordAuthentication no after confirming key logins work, and limit port 22 to trusted IP ranges.
How can I tell if a server was compromised?
Search your auth logs for “Accepted password for” lines on root, alpine or accounts that should only use SSH keys. Then review doas use, new user accounts and authorized_keys files. If you can’t rule out access, treat the host as compromised.