sshhole (CVE-2026-123158): The OpenSSH Login Bypass and How to Check Your Network

On November 5, 2026, the OpenSSH project released OpenSSH 10.6p2 to fix sshhole (CVE-2026-123158), a password-authentication bypass in sshd. It affects Linux systems where OpenSSH is built against musl libc without PAM. Alpine Linux’s default openssh-server package is the main example, which puts many containers, cloud images and small appliances in scope. On an affected server, an account that was never meant to accept a password, such as a key-only user, can be logged into with one.

The name appears in several spellings. The researcher’s site is sshhole.com, the page itself is titled “*sshole”, and coverage writes sshole or SSHole. All of them mean the same bug. Debian, Ubuntu, RHEL and other distributions built on glibc are not affected.

If you are not sure which of your internet-facing servers run SSH, or what they run it on, an external network penetration test finds every exposed SSH service and checks how it is configured. It starts at $4,200, with a free retest.

sshhole at a glance

Item	Detail
What	Password-authentication bypass in OpenSSH sshd
CVE	CVE-2026-123158. CVSS 3.1 score 8.1 High, scored by MITRE as the CNA. NVD had not scored it as of November 6, 2026
Affected	OpenSSH before 10.6p2 on Linux with musl libc and PAM disabled (Alpine by default, other musl systems possibly)
Not affected	glibc distributions, OpenBSD, FreeBSD, macOS, PAM-enabled sshd, PasswordAuthentication no, Dropbear
Fixed	OpenSSH 10.6p2 (November 5, 2026), plus Alpine packages for every branch back to 3.16
Exploited?	Not in CISA’s KEV catalog as of November 6, 2026. CISA rates exploitation “poc”. One vendor, Previdian, reports attempts and a successful root login on its own honeypot (see below)
Do now	Upgrade and restart sshd, or turn off password authentication

Sources: the CVE record, NVD and the Alpine Linux advisory.

What the sshhole OpenSSH vulnerability is

sshhole is not one mistake. It is three behaviors that are harmless on their own and fail together.

1. OpenSSH hashes the typed password even for accounts with no usable hash. Since OpenSSH 7.3 in 2016, sshd does this with a salt borrowed from another account, so an attacker cannot tell real accounts from missing ones by response time. That change was the fix for CVE-2016-6210.
2. musl’s crypt() returns * when it fails. Since 2012, musl has returned the string * on failure rather than NULL, and its SHA-crypt code refuses over-long input.
3. Alpine marks root’s password field with *. Alpine 3.16 (2022) changed root’s field from ! to * after CVE-2019-5021, so key logins keep working while password logins stay blocked. Key-only accounts often carry the same * marker.

Put together, an unusually long password makes the hashing step fail and return *. That matches the * stored for a locked account, and sshd accepts the login.

As OpenSSH’s fix commit puts it: “We do not consider the root cause to be within OpenSSH but we are well equipped to avoid it.” The workaround makes sshd refuse password authentication when the stored hash is shorter than four characters, which a bare * always is.

Found with AI agents, released within a day

The bug was reported by Özgün Kültekin of Wakefield. BleepingComputer reports that he found it with AI agents running about 17,600 authentication tests. His write-up says the tests covered glibc and musl builds, with and without PAM, and only musl without PAM behaved differently.

In the release announcement, OpenSSH’s Damien Miller wrote that the team learned of the bug the day before release. He explained the rush: AI agents have recently rediscovered bugs within hours, so a long embargo now mostly helps attackers.

Who is affected

All four conditions must hold

1. sshd is linked to musl libc and does not use PAM. Alpine’s default openssh-server package is built this way.
2. PasswordAuthentication yes, which is the OpenSSH default.
3. The target account’s password field in /etc/shadow is exactly *.
4. Another local account has a SHA-crypt password hash, one starting with $5$ or $6$, whose salt sshd borrows. TuxCare and IONIX describe a related path where a bcrypt hash plays this role on 10.6p1 and earlier. 10.6p2 blocks that path too.

Which accounts have a * field

• Key-only users created without a password.
• Users mapped in from a directory such as LDAP, sssd or winbind.
• root on Alpine 3.16 and later.
• The alpine user in Alpine’s official tiny-cloud images for AWS, Azure and other clouds.

What about root?

The Alpine advisory says OpenSSH’s default PermitRootLogin prohibit-password protects root, so root is reachable by password only where an administrator set PermitRootLogin yes. Some coverage reported root access on default Alpine installs. Alpine’s advisory does not support that.

The more realistic route to root is the tiny-cloud alpine user, which has passwordless doas. Alpine notes that an attacker who logs in as that user can become root.

Systems that are not affected

OpenSSH, Alpine and the researcher name the systems in the table’s “Not affected” row. The glibc distributions there include Debian, Ubuntu, Fedora and RHEL. TuxCare adds accounts locked with ! rather than *. Containers that do not run sshd have nothing to attack.

Other musl systems

The researcher lists OpenWrt, Buildroot, Yocto, postmarketOS, Void (musl) and Chimera as systems that may be exposed. Treat these as “check them”, not as confirmed. Many embedded builds, OpenWrt among them, ship Dropbear by default, so the question is whether someone added OpenSSH.

CVE-2026-123158 affected and fixed versions

The CVE record lists every OpenSSH version before 10.6p2 on Linux with musl and no PAM. TuxCare says the code path exists from OpenSSH 7.3 (August 2016) through 10.6p1. The researcher tested builds back to 7.5p1 on musl 1.1.16 from 2017.

Alpine published fixed openssh packages for every branch on November 5, 2026 (Alpine advisory):

Alpine branch	Fixed openssh version
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Alpine pushed fixes to end-of-life branches as well. It notes that 3.21 reached end of support on November 1, 2026.

Cloud images. Alpine’s official tiny-cloud images from 3.18.11 through 3.24.3 are affected. They are safe at first boot and become exploitable once any $6$ hash exists on the machine. Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fix.

Some third-party summaries list different package versions for some branches. Use Alpine’s table above as the reference.

Is sshhole being exploited?

Not independently confirmed. As of November 6, 2026, CVE-2026-123158 is not in CISA’s Known Exploited Vulnerabilities catalog. CISA’s enrichment in the CVE record rates exploitation “poc”, automatable “no” and technical impact “total”: proof-of-concept code exists, but CISA had not recorded active exploitation.

Public proof-of-concept labs exist. OX Security advises against running exploit or scanner scripts from public repositories or social media, and to rely on the OpenSSH release and your distribution’s packages. We do not link them here.

One threat-intelligence vendor, Previdian, told Help Net Security that its first exploitation attempt arrived less than nine hours after the CVE was published, and that it confirmed successful root access on one of its own Alpine honeypots. It counted eight attempts, all from a single IP address and caught by one sensor. Its own public page lists four attempts and says the sensor data do not show whether any attempt succeeded. As of November 6, 2026, no source independent of Previdian had confirmed exploitation. A honeypot can also be set up more permissively than a default install: Alpine says root accepts a password only where PermitRootLogin yes is set.

No source has published internet exposure counts, and counts based on version banners would mislead, as the next section explains.

How to check if you are exposed

Check the host

Run these as root on each Alpine or other musl host, container image and cloud image. They read configuration and print account names only, never hashes.

# 1. Is sshd linked against musl?
ldd /usr/sbin/sshd | grep -i musl

# 2. Which openssh-server package is installed? Compare it with Alpine's table.
apk info -v openssh-server

# 3. Which settings is sshd actually running with?
sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|usepam|permitrootlogin) '

# 4. Account names whose password field is exactly "*"
awk -F: '$2 == "*" { print $1 }' /etc/shadow

# 5. Account names with a SHA-crypt or bcrypt hash
awk -F: '$2 ~ /^\$(5|6|2[aby])\$/ { print $1 }' /etc/shadow

A host is exposed when sshd is linked to musl, usepam yes does not appear, password authentication is on, step 4 returns at least one name, step 5 returns at least one name, and the package is older than the fixed version in the table.

Do not trust the version banner

Alpine backports the fix while keeping the upstream version number. On Alpine 3.18, package 9.3_p2-r4 is fixed but still reports OpenSSH 9.3p2. A scanner that flags everything below 10.6p2 will mark patched Alpine hosts as vulnerable, and exposure also depends on configuration, as Ethiack and IONIX both point out. Check the full package version, including the -r release number.

This is where raw scan output and a reviewed result differ. Our vulnerability scanning service starts at $1,500 per scan, with an analyst confirming findings and removing false positives like this one. Our guide to penetration testing vs vulnerability scanning explains when each fits.

Check the logs

Search /var/log/messages, or wherever your auth log goes, for Accepted password for and compare the account names with the list from step 4. Alpine advises treating the host as compromised if you find such a login and cannot rule out an attack. BleepingComputer notes that this pattern could indicate exploitation.

TuxCare saw a failed attempt from the same source port just before the accepted one in its lab. Treat that as a hint, not proof: many containers run no syslog daemon, a mistyped legitimate login can produce the same pair, and an attacker with root can clean logs. Ethiack notes that no network indicators had been published.

The researcher’s check script

The researcher’s public repository includes check.sh, which reports the libc, sshd version, PAM build, PasswordAuthentication setting, * accounts and SHA-crypt hashes, then gives an exposed or not-exposed verdict. The same repository also holds proof-of-concept code, which is why we do not link it. The five commands above cover the same checks. If you use the script, read it before you run it as root.

How to fix sshhole

1. Upgrade to OpenSSH 10.6p2 or your distribution’s fixed package. On Alpine, run apk upgrade -U -a.
2. Restart sshd with rc-service sshd restart. Upgrading the package does not replace the daemon that is already running.
3. Rebuild container and cloud images from a fixed base and redeploy them. Old images still carry the vulnerable package.
4. If you cannot patch yet, set PasswordAuthentication no and KbdInteractiveAuthentication no. Confirm key-based login works first, validate with sshd -t, then check the result with sshd -T. TuxCare notes that on Alpine 3.18 and older, a drop-in file in sshd_config.d alone has no effect, so edit /etc/ssh/sshd_config directly.
5. Reduce exposure regardless. Restrict port 22 to a VPN, a bastion host or allow-listed addresses, remove sshd from containers that do not need it, and keep PermitRootLogin prohibit-password.

Then confirm the fix took, using the steps in our guide to vulnerability remediation.

If you find a password login on a * account

Treat the host as compromised: Alpine, TuxCare and IONIX all advise this. Review recent doas use, new users, new authorized_keys entries, changed files and new cron jobs. We also recommend rebuilding from a known-good image and rotating the keys and secrets the host held.

How a penetration test finds sshhole

External. The tester finds every internet-facing SSH service, fingerprints the ones running on Alpine or other musl systems, and checks whether they offer password authentication. That proves the precondition only, and the version banner settles nothing either way. Our guide to external attack surface management covers keeping that inventory current between tests.

Internal and credentialed. A configuration review of hosts, container images and cloud images against the four conditions above finds sshhole with no exploitation at all. This fits naturally into an internal network penetration test, from $6,000.

Validation. Proving the bypass needs a real login attempt, so it happens only with written authorization, against designated test accounts or a staging clone. OpenSSH 9.8 and later throttle repeated attempts from one source, and IONIX advises treating a disconnect before the SSH banner as “unknown”, not “clean”.

The report gives the fix (patch and restart, or disable passwords), and the retest confirms it. To prepare, use our network penetration testing checklist.

Timeline

Date	Event
November 4, 2026	OpenSSH learns of the bug, per Damien Miller’s announcement
November 5, 2026	OpenSSH 10.6p2 and Alpine’s fixed packages released. CVE-2026-123158 published at about 15:46 UTC
November 6, 2026	Help Net Security reports Previdian’s claims of attempts and a honeypot root login. Still not in CISA’s KEV catalog

For the rest of what was exploited in October 2026, see our roundup of October 2026 exploited vulnerabilities.

An external network penetration test starts at $4,200, fixed in writing before work begins, with a free retest of everything you fix.

Frequently asked questions

Is Ubuntu or Debian affected by sshhole? No. Ubuntu, Debian, Fedora and RHEL use glibc, and the bug needs musl libc. An sshd that checks passwords through PAM is not affected on any distribution.

Are sshhole and sshole the same bug? Yes. sshhole, sshole, SSHole and the researcher’s own spelling all refer to CVE-2026-123158.

Does turning off password authentication fix sshhole? It removes one of the four conditions, so the bypass stops working. Turn off keyboard-interactive authentication as well, then still patch and restart sshd so a later configuration change cannot reopen it.

My scanner flags OpenSSH 9.3p2 on Alpine. Am I vulnerable? Not necessarily. Alpine backported the fix without changing the upstream version, so on Alpine 3.18 the package 9.3_p2-r4 is fixed. Compare the full package version, including the release number, against Alpine’s table.

Is sshhole in CISA’s KEV catalog? No, not as of November 6, 2026. CISA’s enrichment of the CVE record rates exploitation as “poc”, meaning proof-of-concept code exists without confirmed active exploitation. Previdian has separately reported a successful root login on one of its honeypots, which no other source had confirmed as of November 6, 2026.

Fixed price, fixed scope, free retest. Scope your network penetration test and get the price in writing.