Free *sshole scanner - check for CVE-2026-123158 in OpenSSH
Scan your SSH server for *sshole (CVE-2026-123158), the OpenSSH password authentication bypass on Alpine and other musl-based Linux, with this free scanner and download a PDF report you can share with your team.
It shows whether your server lets a locked account log in with an oversized password, the evidence behind the finding (the successful login and the output of the id command), and the fix to apply.
Already patched? Use this free *sshole checker to confirm your server no longer accepts a long password for a locked account.
Running fail2ban? Allowlist our scanning IPs first, or the scan can stop after five accounts and still look clean.
- Scan type
Light scan
Scan your SSH server for *sshole (CVE-2026-123158), the OpenSSH password authentication bypass on Alpine and other musl-based Linux, with this free scanner and download a PDF report you can share with your team.
It shows whether your server lets a locked account log in with an oversized password, the evidence behind the finding (the successful login and the output of the id command), and the fix to apply.
Already patched? Use this free *sshole checker to confirm your server no longer accepts a long password for a locked account.
Running fail2ban? Allowlist our scanning IPs first, or the scan can stop after five accounts and still look clean.
Am I affected by *sshole?
You're affected if all of these are true for a server:
sshd runs on musl libc: Alpine Linux, embedded Linux built with Buildroot or Yocto, or OpenWrt devices that run OpenSSH instead of Dropbear
sshd checks passwords without PAM: Alpine's standard
openssh-serverpackage, or any build running withUsePAM nopassword logins are on:
PasswordAuthentication yes, the OpenSSH defaultan account has only
*in/etc/shadow, such as a key-only user, an LDAP user, or root on Alpine 3.16 and lateranother local account has a real password hash (SHA-256 or SHA-512,
$5$or$6$)
Then the * account accepts any password between 257 and 1,024 characters.
Not affected: Linux with glibc (Debian, Ubuntu, Fedora, and most other big distributions), any system where PAM handles password logins, non-Linux systems such as OpenBSD, and Dropbear.
Update OpenSSH to 10.6p2 or your Alpine branch's fixed package, then restart sshd. Can't update today? Set PasswordAuthentication no.
How we detect *sshole
The SSH banner tells you which OpenSSH version a server runs. It doesn't show the C library underneath, whether sshd uses PAM, or which accounts have a * in /etc/shadow, and *sshole (CVE-2026-123158) needs all of them. So our scanner doesn't guess from the banner. It tries the login itself against 15 common system accounts, and the whole check takes about a minute.
Login attempt: it tries to log in over SSH with an oversized password (over 256 bytes) as the 15 most common accounts in a default
/etc/passwd:root,bin,daemon,adm,lp,sync,mail,news,uucp,operator,games,ftp,nobody,sshd, andman. It makes one attempt per account, and a patched server rejects every one.Shell session: if the server accepts the password, the scanner opens a session, runs the
idcommand, and logs off.Confirmation: the finding includes the successful login and the
idoutput, so you can verify it yourself or pass it to whoever owns the fix. Because the scanner ran a command on your server, the finding is marked Confidence: Certain.
What each result tells you
| Result | What it shows | What it doesn't show |
|---|---|---|
| Login match | The server accepted an oversized password for a locked account, and the id output shows the session was real (Confidence: Certain) | Exposure through accounts outside our list, such as the alpine user on Alpine's cloud images, or your own key-only and LDAP users |
| No match | None of the 15 system accounts we tried let us in | That the server is patched. A * account outside our list, or password logins switched back on later, can still expose it. If a tool like fail2ban blocked our scanning IP, the report still shows a clean result, with no warning that the scan stopped early |
Before you scan production
On a vulnerable server, the check really logs in, so the login shows up in /var/log/messages like this:
Nov 2 03:14:07 your-box sshd[2211]: Accepted password for alpine from <our_scanning_ip> port 41822 ssh2Let whoever watches your auth logs know before you scan, so our login doesn't trigger an incident (or get mistaken for one later).
The check logs off right after running id, so it doesn't leave a session open on your server. On a patched server, you'll see failed password attempts instead: one for each of the 15 accounts.
If you run fail2ban or a similar tool, allowlist our scanning IPs before you scan. With default settings, fail2ban blocks the scan after five accounts. The rest never get tested, and the report still shows a clean result, with no warning that the scan stopped early.
An external scan can't read /etc/shadow or know every account name on a server, so a clean result doesn't prove the box is patched. Check the package with apk info -v | grep openssh and the setting with sshd -T | grep -i passwordauthentication.
A standard SSH version banner can't settle *sshole, because the flaw comes from an environmental collision, not an isolated code version. It needs OpenSSH linked against musl libc (glibc is immune), PAM disabled, password authentication on, and a target account locked with an asterisk in /etc/shadow. A banner, a backported distro patch, or a stale in-memory daemon reveals none of that.
To cut through the ambiguity, our check confirms exploitability end to end. It attempts an SSH login with an oversized (over 256-byte) password, opens a shell session, and runs the id command to verify that an unauthenticated remote session was genuinely established.
We validated this workflow in an Alpine lab environment on an asterisk-locked account. The oversized password forced musl's hashing routine to return *, which matched the shadow record, granted access, and returned the target UID and GID with zero credentials, until we deployed the patch.
Product Security Manager at Pentest-Tools.com
Free *sshole scanner report (PDF) sample
Once the scan finishes, you get a PDF report you can share with whoever handles remediation. For *sshole, it includes:
the finding, with the successful login and the output of the
idcommand behind itthe fix to apply: OpenSSH 10.6p2 or your vendor’s patched build (on Alpine, the updated
opensshpackage for your branch)the severity rating and a workaround for servers you can't patch right away: turning password logins off with
PasswordAuthentication no
The report also lists the open ports, DNS records, and technologies the scan found along the way.
id output, and Confidence: Certain. 
What is *sshole?
Technical details
*sshole is a password authentication bypass in OpenSSH's sshd on Linux systems that use the musl C library and check passwords without PAM. The OpenSSH team considers the root cause to sit outside sshd, and patched sshd because that's where the bug can be triggered.
Three decisions, each reasonable on its own, line up to cause it:
- 2012, musl:
crypt()stops returning NULL on failure and returns*instead, because many programs never checked for NULL. Twenty days later, musl's SHA-512 crypt refuses passwords longer than 256 bytes, so very long passwords can't tie up the server. - 2016, OpenSSH: to close a timing leak that revealed which usernames exist (CVE-2016-6210), sshd hashes the password with another account's salt whenever the target account has no usable hash.
- 2022, Alpine: Alpine 3.16 locks root with
*instead of!, so key logins keep working without PAM.
Put together: an attacker logs in as a * account with a 300-character password. sshd hashes it with another account's SHA-512 salt, musl gives up past 256 bytes and returns *, and sshd compares * with *. They match.
OpenSSH 10.6p2 makes sshd refuse a match when the stored value is shorter than four characters.
Özgün Kültekin of Wakefield found it by building sshd every way he could (glibc, musl, PAM, no PAM) and throwing about 17,600 unusual logins at each build with AI agents. Only musl without PAM said yes when it shouldn't have.
Versions vulnerable to *sshole
| Component | Vulnerable versions | Fixed in |
|---|---|---|
| Portable OpenSSH (upstream) | Releases before 10.6p2, built on musl without PAM | 10.6p2 |
| Alpine edge | openssh-server below 10.6_p2-r0 | 10.6_p2-r0 |
| Alpine 3.24 | Below 10.3_p1-r2 | 10.3_p1-r2 |
| Alpine 3.23 | Below 10.2_p1-r1 | 10.2_p1-r1 |
| Alpine 3.22 | Below 10.0_p1-r11 | 10.0_p1-r11 |
| Alpine 3.21 | Below 9.9_p2-r1 | 9.9_p2-r1 |
| Alpine 3.20 | Below 9.7_p1-r6 | 9.7_p1-r6 |
| Alpine 3.19 | Below 9.6_p1-r3 | 9.6_p1-r3 |
| Alpine 3.18 | Below 9.3_p2-r4 | 9.3_p2-r4 |
| Alpine 3.17 | Below 9.1_p1-r7 | 9.1_p1-r7 |
| Alpine 3.16 | Below 9.0_p1-r6 | 9.0_p1-r6 |
| Alpine tiny-cloud images (AWS, Azure) | 3.18.11 through 3.24.3 | 3.21.10, 3.22.8, 3.23.8, 3.24.4 |
| OpenWrt with OpenSSH | Devices that replaced Dropbear with OpenSSH | Fixed package submitted to the OpenWrt feed |
Sources: Alpine advisory, Alpine package index via PrivacyAffairs, OpenSSH 10.6p2 release notes, Security Boulevard (fixed versions table), OpenWrt packages PR. openssh-server-pam uses the same version numbers.
Version numbers don't give you the full picture. Alpine backported the fix, so a lower OpenSSH version can be patched, and an updated package doesn't protect you until sshd restarts. Check with apk info -v | grep openssh, then restart.
*sshole severity score unpacked
*sshole is tracked as CVE-2026-123158, with a CVSS 3.1 score of 8.1 (High) in the CVE record (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). NVD analysis is pending. The OpenSSH team calls it critical.
The 8.1 score and the urgency behind it come down to three things:
- No credentials required: the attacker needs an account name and network access to the SSH port, nothing else.
- One attempt: according to Alpine, exploitation takes a single connection, with no brute forcing and no race to win.
- Default-friendly conditions: Alpine's standard OpenSSH package skips PAM, and password logins are on by default.
The score marks attack complexity as High because several conditions have to line up. When they do, exploitation is trivial.
If leadership asks, here's the executive summary: any SSH server on Alpine or other musl-based Linux that still allows password logins is open until OpenSSH is updated and sshd restarts. Servers that only take keys can't be reached through this bug, and they still need the update, because someone can turn password logins back on later.
*sshole disclosure timeline
| Date | Event |
|---|---|
| August 2012 | musl's crypt() starts returning * on failure, and SHA-512 crypt gets a 256-byte password cap |
| July 2016 | OpenSSH fixes CVE-2016-6210 by hashing passwords for accounts without a usable hash with another account's salt |
| May 2022 | Alpine 3.16 locks root with * instead of ! |
| October 30, 2026 | OpenSSH fixes fake salt generation for bcrypt hashes in pick_salt(), a few lines above the bug |
| November 4, 2026 | Özgün Kültekin of Wakefield reports the bug to OpenSSH |
| November 5, 2026 | OpenSSH releases 10.6p2. Alpine ships fixed packages back to 3.16 and publishes its advisory. The write-up goes public |
| November 5, 2026 | MITRE publishes CVE-2026-123158 |
| November 2026 | We add detection for *sshole to the Network Vulnerability Scanner |
| November 2026 | We launch this free *sshole scanner |
*sshole exploitation - what attackers can do with it
Here's what's been shown so far, and what hasn't:
No credentials required: an attacker who can reach the SSH port and knows the name of a
*account can log in with a password of 257 to 1,024 characters.One connection: Alpine's advisory says no repeated attempts are needed when the conditions line up.
Public trigger: the researcher's write-up shows the input (300 × "A") and includes an in-browser demo of the comparison.
Exploited in the wild: no public reports as of November 5, 2026. Public reproduction labs are linked from the CVE record, and CISA’s assessment on the record rates exploitation as proof of concept.
CISA KEV: not listed.
If an attacker gets in, the impact depends on the account. They get a shell with that account's permissions, which puts these in reach:
root on Alpine's official AWS and Azure images: the default
alpineuser has*as its password and passwordlessdoas, so a login turns into root once any other account has a real passwordkey-only deploy users and service accounts, with whatever they hold: CI secrets, deploy keys, database credentials
LDAP users whose local shadow entry is
*root itself, only where
PermitRootLoginwas changed to allow passwords
The bug needs at least one other account with a real password hash, so a fresh box where nobody has set a password isn't exposed. Most servers that have been in use for a while don't fit that description.
Check if someone already got in. Search the log for password logins with grep "Accepted password" /var/log/messages (Alpine's default log file). For each account you find, check its line in /etc/shadow. If the second field is only *, that account should never have logged in with a password. Unless the login came from our scanning IPs during a scan you ran, treat the machine as compromised, and look for unexpected doas activity and new authorized keys.
Need to show what an attacker gets, not only that the door is open?Sniper, our auto-exploitation tool, exploits *sshole (CVE-2026-123158) on servers you're authorized to test, so you can show the real impact in your pentest report. It's available in the Exploit plan.
See the Exploit planHow to mitigate *sshole
The fix is updating OpenSSH and restarting sshd. Pick the path that matches what you run.
Upgrade paths:
Alpine: run
apk update && apk upgrade, thenrc-service sshd restart. Every current branch has a fixed package, and Alpine committed the fix back to 3.16.Upstream OpenSSH: build 10.6p2 or later.
Containers: rebuild every Alpine-based image that runs sshd, then redeploy.
Embedded (Buildroot, Yocto): pull in OpenSSH 10.6p2, or turn password logins off in the image, then ship a firmware update.
OpenWrt with OpenSSH: update the package once the fix lands in your feed.
If you can't update right away, these temporary controls close the door while you schedule the fix:
Set
PasswordAuthentication noin/etc/ssh/sshd_config(or a file insshd_config.d), checkMatchblocks that switch it back on, and confirm withsshd -T | grep -i passwordauthentication. Make sure your own key login works first.Allow SSH only from addresses you trust, in your firewall or cloud security group.
Stop sshd on hosts that don't need it.
Note: don't "fix" a * account by deleting its password field. An empty password is a different, worse problem.
Get a free *sshole scan report
*sshole references
- Pentest-Tools.com Vulnerability & Exploit Database - *sshole (CVE-2026-123158)
- CVE.org - CVE-2026-123158
- NVD - CVE-2026-123158
- Özgün Kültekin (Wakefield) - *sshole write-up
- OpenSSH - 10.6p2 release notes
- Alpine Linux - OpenSSH password authentication bypass advisory
- Damien Miller - OpenSSH 10.6p2 announcement
- LWN - Critical security vulnerability affects OpenSSH on Alpine Linux systems
- musl - make crypt return an unmatchable hash rather than NULL (2012)
- OpenSSH - determine appropriate salt for invalid users (2016)
- Alpine aports - lock root with * instead of ! (2022)
- OpenWrt packages - OpenSSH update pull request
- PrivacyAffairs - OpenSSH rushes out a fix for a password bypass on Alpine
About our Network Vulnerability Scanner
Our Network Vulnerability Scanner is a well-rounded tool for all your network security assessments.
It combines multiple engines and fine-tuned scan settings that surface more than 17,500 vulnerabilities, misconfigurations, and outdated services.
Each scan automatically updates your attack surface and provides an up-to-date map for planning targeted attacks or strategic lateral movements.
Explore a sample report, which includes a vulnerability summary, automatically confirmed findings, evidence, and more.
See what else it can doIn a transparent benchmark, our tool outperformed the 6 most popular network scanners on the market, both open-source and commercial.
FAQs
What is *sshole?
*sshole is the name Özgün Kültekin of Wakefield gave a password authentication bypass in OpenSSH on musl-based Linux without PAM. Accounts that should never accept a password take any password between 257 and 1,024 characters. It’s tracked as CVE-2026-123158 (CVSS 8.1, High), and OpenSSH fixed it in 10.6p2.
Why does the name have an asterisk?
The * is the bug. It's the character Unix puts in /etc/shadow to mean "no password login," and it's also what musl's crypt() returns when hashing fails. When the two meet, they match. The name is a pun on that, so you'll also see it written as sshole.
Is *sshole a remote code execution vulnerability?
Not in the usual sense. It's an authentication bypass: the attacker logs in as an account and gets whatever shell and permissions that account has. On Alpine's official AWS and Azure images, that account can become root through passwordless doas.
Am I affected on Debian, Ubuntu, or Fedora?
No. Those distributions use glibc, and the bug needs musl. Systems where PAM handles password logins aren't affected either, whatever C library they use.
Does *sshole affect Dropbear or OpenWrt?
Dropbear isn't affected: Alpine's and musl's maintainers both checked its source. OpenWrt routers run Dropbear by default, so they're only exposed if someone replaced it with OpenSSH.
Does *sshole have a CVE?
Yes: CVE-2026-123158, published on November 5, 2026, after Alpine’s advisory went out without one. Use it in tickets and scanner exceptions.
Should I remove the * from accounts in /etc/shadow?
No. An empty password field can let anyone in with no password at all. Keep the *, update OpenSSH, restart sshd, and turn password logins off where you don't need them.
Why are you offering a free scanner for *sshole?
Every day, our team develops tools, detections, and exploits to help security professionals find vulnerabilities before attackers can exploit them.
We know the fight is unfair: security teams follow strict rules, while threat actors do whatever they want. That's why we build free tools like this one, so security teams can validate their exposure quickly, without waiting for a scheduled scan or a costly engagement.