Also written sshole and sshhole · CVE-2026-123158 · OpenSSH server on Linux with musl, without PAM
On November 5, 2026, the OpenSSH project released Portable OpenSSH 10.6p2. It closes a flaw that lets attackers log in over SSH without a password: on Linux systems with the musl C library whose SSH server checks passwords without PAM, such as Alpine Linux. There, any password of 257 to 1,024 bytes opens accounts with a * in the password field, provided another account has a password. Systems with glibc such as Debian, Ubuntu or RHEL are not affected. Check here within minutes whether your servers, containers and devices are affected, or have VamiSec check them at short notice.
Self-test in your browserRead-only check commandsTests only with written approval
Independent analysis by VamiSec GmbH, not affiliated with the OpenSSH project, Alpine Linux or the discoverer of the flaw. The original write-up is at sshhole.com.
257 bytesfrom this password length, crypt() in musl fails and returns "*"
1 charactera "*" in the password field turns an account without a password into a target
8.1CVSS 3.1 in the CVE record, severity high
2016the bug has been in the code since OpenSSH 7.3p1
< 2 daysfrom the report to the release of OpenSSH 10.6p2
At a glance
The 7-point plan against *sshole
From the outside in: first find out which SSH services accept passwords, switch password login off there and patch in parallel. Internal systems, images and devices follow. Supply chain, forensics and documentation run from day one.
Inventory all reachable SSH services: servers, bastion hosts, containers with sshd, routers and devices. Flag those that run on musl and accept passwords.
Outside · now
Turn off password login
On musl systems without PAM, set PasswordAuthentication no, test key login first, validate and restart sshd. This closes the hole immediately.
Outside · in parallel
Patch and restart
Install OpenSSH 10.6p2 or the fixed Alpine packages, restart sshd, rebuild images. A package update alone does not replace the running daemon.
Only once the outside is done
Inside · afterwards
Update images and accounts
Update internal servers, container images, golden images and cloud templates. Inventory accounts with * in the password field and accounts with a password hash.
Supply chain · from day 1
Ask your vendors
Ask vendors of routers, appliances and devices built on OpenWrt, Buildroot or Yocto in writing about exposure, patch status and evidence.
Complementary · ongoing
Look for traces
Search logs for password logins to accounts without a password, review doas use, new accounts and SSH keys.
Ongoing
Document and report
Record inventory, patch times and findings; if there are signs of exploitation, check reporting duties under NIS2, GDPR, DORA and the CRA.
*sshole is the name for CVE-2026-123158, a flaw in the OpenSSH server sshd on Linux systems that use the musl C library, when sshd checks passwords without PAM. For accounts whose password field contains only an asterisk *, sshd then accepts any password of 257 to 1,024 bytes. It comes from two decisions working together: musl reports a password hashing error with the string *, and sshd compares exactly that string with the stored *.
Impact: Anyone who can reach the SSH port and knows the name of such an account logs in without a password. In Alpine's official cloud images this leads to root via the alpine account and passwordless doas, as soon as any account on the machine has a password.
Preconditions: musl, sshd without PAM, password login enabled (the OpenSSH default), an account with exactly * in the password field and another local account with a suitable password hash, typically SHA ($5$ or $6$). If one is missing, the flaw does not apply.
Not affected: Debian, Ubuntu, RHEL, Fedora and other systems with glibc, systems that check passwords via PAM, Dropbear, OpenBSD and containers without a running sshd.
Fix: Install OpenSSH 10.6p2 or your distribution's fixed packages and restart sshd. PasswordAuthentication no works immediately, once key login has been tested.
Check: At short notice, VamiSec determines from the outside which of your SSH services accept passwords, and from the inside which systems, images and devices meet the preconditions.
The order follows the risk, from the outside in. For *sshole, outside means every SSH service an attacker can reach: from the internet, from partner networks or from a network segment that is already compromised. The most effective immediate action takes minutes: turn off password login.
Outside · nowPoint 1
Gain visibility
Inventory all SSH services, starting with those reachable from the internet: servers, bastion hosts, containers and pods with their own sshd, CI runners, routers, firewalls, NAS and other devices. For each service, three questions matter: Does OpenSSH run on musl? Does sshd check passwords without PAM? Does it accept passwords at all?
Whether a server offers password authentication shows up when you connect without logging in (check commands). The version string in the SSH banner is only a hint: it does not reliably reveal the distribution, and patched Alpine packages keep reporting their old OpenSSH version.
Outside · nowPoint 2
Turn off password login
On all musl systems without PAM, set PasswordAuthentication no and restart sshd. This closes the hole completely, even before the update. Test key-based login first and keep your current session open until a new login succeeds.
Two pitfalls: Alpine only reads drop-in files in /etc/ssh/sshd_config.d/ from 3.19 onward, and a Match block can re-enable password login for individual users. Alpine's commands take care of both (interim measures).
Outside · in parallelPoint 3
Patch and restart
Install OpenSSH 10.6p2 or your distribution's fixed packages, on Alpine with apk upgrade -U -a. Then restart sshd, on Alpine with rc-service sshd restart: a package update does not replace the running daemon. Rebuild and redeploy container images that contain sshd.
Check the package version, not the version output of sshd. Alpine backported the fix to its stable branches, where sshd keeps reporting, for example, OpenSSH_10.3p1. The version table shows which packages contain the fix.
Outside · until patchedPoint 3
Interim protection where passwords must stay
If individual users need passwords, for example on an SFTP service, at least turn off password login for all accounts without a password, for example with a Match block. Alternatively, let PAM check passwords: Alpine lists openssh-server-pam with UsePAM yes as not affected. In addition, restrict SSH access to known networks, a VPN or a bastion host.
Only once all SSH services reachable from the outside no longer accept passwords or are patched, move inward.
Inside · step by stepPoint 4
Update images and accounts
Then update internal servers, container images, golden images and cloud templates. Record which accounts have exactly * in the password field and which local accounts carry a password hash. A single account with a password is enough to make all accounts without a password vulnerable. According to Alpine, users from directory services integrated via musl-nscd are targets too, because they have no entry in /etc/shadow.
Supply chain · from day 1Point 5
Ask your vendors
musl and OpenSSH without PAM are common in embedded systems. OpenWrt uses musl, Buildroot and Yocto can build with it, and firmware for routers, gateways, appliances and industrial devices is made with them. Ask vendors who have not informed you on their own for a written statement: Does the product use OpenSSH on musl without PAM? Is password login possible? When will an update ship, with what evidence? For entities under NIS2 and financial entities under DORA, managing supply chain risk is a duty anyway.
OngoingPoint 6
Check for signs of attack
Search the sshd logs for Accepted password for on accounts that have no password at all, such as alpine, root or key-only accounts. On Alpine these entries are in /var/log/messages. On exposed systems, review doas use, newly created accounts, files and authorized_keys. If you cannot rule out a login, treat the system as compromised. Alpine recommends the same. Indicators are in the detection section.
If there are signsPoint 6
Rebuild and rotate credentials
Anyone who had SSH access to a system may have taken keys, tokens and passwords and left backdoors behind. Rebuild affected systems from trusted sources, rotate SSH keys, credentials and tokens that were stored there, and check whether the attacker reached other systems from there.
OngoingPoint 7
Document and check reporting duties
Record inventory, patch times, vendor responses and findings. If there are signs of exploitation, check your reporting duties under NIS2, GDPR, DORA or the CRA.
Interim measure · Alpine and other musl systems
Turn off password login
The commands from the Alpine advisory create a drop-in file, set every PasswordAuthentication line in /etc/ssh/sshd_config to no, including lines in Match blocks, and keep the original as sshd_config.bak. Run as root, test key login first:
The last line must print passwordauthentication no. To undo: delete the drop-in file and copy sshd_config.bak back.
Interim measures · when passwords must stay
Reduce the attack surface
Allow password login only for accounts that really need a password, turn it off for all others with a Match block and PasswordAuthentication no
Let PAM check passwords: on Alpine with openssh-server-pam and UsePAM yes. Without UsePAM yes this package is affected too, the OpenSSH default is no
Make SSH reachable only from known networks, via VPN or a bastion host
Do not set PermitRootLogin to yes. The default prohibit-password protects root from direct login
Run containers with sshd only where really needed. Without a running sshd the flaw does not exist
These measures reduce the attack surface but do not replace the update. Test every change with a second session before closing the first.
02 · Overview
What is behind *sshole
The name plays on the character at the heart of the flaw: the asterisk in the password field of /etc/shadow. For decades, a * there has stood for an account without a usable password. No password should ever match it. Such accounts are common: on Alpine Linux, root carries an asterisk in the base image since about version 3.16, as do accounts used only with SSH keys and the alpine account in the official cloud images.
The flaw was found by Özgün Kültekin of Wakefield. According to the write-up, Kültekin built sshd in every conceivable variant, with glibc and musl, with and without PAM, with and without shadow passwords, and had agent swarms run around 17,600 unusual login attempts against them. The combination of musl without PAM stood out. The report went to the OpenSSH project on November 3; OpenSSH 10.6p2 came out on November 5, and, according to the discoverer, Alpine published patched packages in the same minute.
The OpenSSH project considers the root cause to be outside sshd but defused the flaw where it is exploitable. OpenSSH developer Damien Miller advised operators of affected systems to turn off password login or SSH altogether immediately. According to Miller, the team now considers long embargo periods dangerous, because AI agents rediscover reported bugs, sometimes within hours. As a result, less than two days passed between the report and the release.
The case shows how the pace is shifting. Already in the release notes for OpenSSH 10.5 and 10.6, the project reported many bug reports that come from AI models or were made with AI assistance. Several bugs found by AI were later rediscovered independently. The project therefore announced more frequent releases. For operators, this means less and less time between disclosure and the first attack attempts. If you do not know where which version runs with which configuration, you lose that time searching.
Login without a password
Anyone who can reach the SSH port and knows the name of an account with * logs in with any password of 257 to 1,024 bytes. According to Alpine, it takes a single connection and works every time. The attacker gets a session with that account's privileges.
Up to root via doas
Alpine's official tiny-cloud images from 3.18.11 through 3.24.3 ship the alpine account with * and passwordless doas. They are only safe as long as no account on the machine has a password. Once an admin sets a console password, for example, a login as alpine becomes a path to root.
Direct root login usually protected
On Alpine, root carries an asterisk as well, but the OpenSSH default PermitRootLogin prohibit-password protects it from direct password login. Root becomes directly reachable only with PermitRootLogin yes. Via other accounts with doas or sudo, the path leads there anyway.
03 · Vulnerability
One CVE, five preconditions
The CVE ID was assigned by MITRE, not by the OpenSSH project. Whether a system is vulnerable is not decided by the OpenSSH version alone, but by the combination of C library, build, configuration and accounts.
Description in the CVE record · CNA MITRE · published Nov 5, 2026
CVE-2026-123158: password authentication bypass in sshd on musl without PAM
According to the CVE record, sshd in OpenSSH before 10.6p2 on Linux with musl and without PAM lacks a workaround for a password authentication bypass, related to misinterpreting whether a string is meant to be a password hash. For some account configurations, any very long password then succeeds. The record says 256 to 1,024 characters; tests by the discoverer and by Alpine show 257 to 1,024 bytes. The record names Alpine Linux as an example.
Affected: sshd in OpenSSH before 10.6p2 on Linux with musl, when passwords are checked without PAM. The bug was introduced in 2016 with OpenSSH 7.3p1. The discoverer confirmed it as far back as OpenSSH 7.5p1 with musl 1.1.16 from 2017.
Fixed: OpenSSH 10.6p2 with the commit "avoid password authn bypass", plus backported packages in Alpine 3.16 to 3.24 and edge
Weakness per the CVE record: unexpected status code or return value (CWE-394). Red Hat maps it to CWE-303, an incorrect implementation of an authentication algorithm
Found by: Özgün Kültekin, Wakefield
CVSS 3.1 8.1CWE-394CISA SSVC: PoC · total
About the CVSS score: MITRE rates the flaw 8.1 under CVSS 3.1 (vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The attack works over the network, without privileges and without user interaction. The high attack complexity AC:H reflects the preconditions. Once they are met, the attack needs no exploit technique at all: a long password is enough. OpenSSH itself calls the flaw critical. In its assessment of November 5, the US agency CISA records: proof of concept available, not automatable, total technical impact.
The five preconditions
A system is vulnerable only if all five apply. In addition, the attacker must reach the SSH port and know the name of a target account. Names like root, alpine or git are easy to guess.
Preconditions for *sshole according to the Alpine advisory, OpenSSH and the discoverer (as of Nov 6, 2026)
Precondition
What it means
How to check
1 · musl C library
Alpine Linux, OpenWrt, postmarketOS, Void Linux (musl), Chimera Linux, plus firmware from Buildroot or Yocto when built with musl. Systems with glibc such as Debian, Ubuntu, RHEL, Fedora and SUSE are not affected.
ls /lib/ld-musl-*.so.1
2 · sshd checks passwords without PAM
Alpine's openssh-server package is built without PAM. openssh-server-pam is only protected with UsePAM yes; the OpenSSH default is no.
sshd -T | grep -i usepam no output: sshd built without PAM
3 · Password login enabled
PasswordAuthentication yes is the OpenSSH default unless configured otherwise. According to Alpine, images set up via cloud-init turn it off.
sshd -T | grep -i passwordauthentication
4 · Target account with exactly *
On Alpine, root (but protected by PermitRootLogin), key-only accounts without a password, directory users via musl-nscd, the alpine account in the cloud images. Locked accounts with ! are not affected.
awk -F: '$2=="*"{print $1}' /etc/shadow
5 · Salt donor with a password hash
Another local account with a password hash, typically SHA ($5$, $6$). A single user with a password is enough. Strictly, according to IONIX, the first account with a hash in /etc/passwd counts: bcrypt ($2…$) works before 10.6p2 even with a short password, MD5 ($1$) and yescrypt ($y$) do not.
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow
Run all commands as root; they change nothing. On Alpine with openssh-server-pam the binary is called sshd.pam. More commands are in the check commands; the self-test evaluates your answers.
04 · Technical background
How a long password becomes a key
Without PAM, sshd checks a password itself: it hashes the input with the C function crypt() and compares the result with the stored field. Two decisions from 2012 and 2016, each reasonable on its own, together create the flaw.
Input
Long password
The attacker logs in to an account with * and sends a password of 257 to 1,024 bytes, for example the letter A 300 times.
Borrowed salt
No salt in the asterisk
A * contains no salt. Since 2016, sshd then borrows the salt of another account, so that the response time does not reveal whether an account exists.
Error as a value
crypt() returns "*"
musl hashes at most 256 bytes with SHA-crypt. For longer input, crypt() fails and returns the string * as its error marker.
Impact
"*" equals "*"
sshd compares the supposed result * with the stored *. Both are equal, so the login counts as successful.
Simplified illustration based on the OpenSSH 10.6p2 release notes, the fix commit, the Alpine advisory and the discoverer's write-up. Above 1,024 bytes, sshd rejects a password before it reaches crypt().
Root cause in musl · 2012
An error that looks like a hash
Since August 2012, musl returns the string * instead of a null pointer when crypt() fails. That was meant to protect programs that do not check the result, because normally no stored hash matches a *. Shortly afterwards, SHA-crypt arrived with a 256-byte limit for the password. glibc and libxcrypt report errors differently, with a null pointer or *0, never with a single *.
Root cause in OpenSSH · 2016
The borrowed salt
Against CVE-2016-6210, guessing valid user names from response times, sshd has hashed passwords since OpenSSH 7.3p1 even for accounts without a usable hash. If the stored field is too short for a salt, the function pick_salt() takes the salt of the first account with a real hash. sshd kept comparing against the stored field. That comparison now meets musl's asterisk.
Fix · OpenSSH 10.6p2
At least four characters
The commit "avoid password authn bypass" only allows a match if the stored hash is at least four characters long. A single * can never match again, whatever salt sshd uses. In addition, sshd now works with its own copies of the password fields instead of pointers into static buffers of the C library. The project explicitly calls the fix a workaround in sshd and says the root cause lies elsewhere.
In practice · for testers
One connection, two attempts
The discoverer's public proof of concept first sends any wrong password and then a 300-character password within one connection. According to a lab analysis by IONIX, the first attempt per connection fails because of the state of an internal buffer. Test tools that send only one attempt per connection can therefore miss vulnerable systems. Also according to IONIX, before 10.6p2 even a short password is enough if the first account with a hash carries a bcrypt hash. 10.6p2 closes this case as well.
05 · Exposure
Which systems are affected
What matters is not the distribution alone, but whether sshd runs on musl and checks passwords without PAM. Alpine backported the fix to its stable branches without changing the OpenSSH version. The package version therefore decides, not the output of sshd -V.
Alpine Linux: fixed packages per branch according to the Alpine advisory of Nov 5, 2026. The "sshd reports" column is derived from the upstream version.
Branch
Fixed from openssh package
sshd reports
Note
edge
10.6_p2-r0
OpenSSH_10.6p2
development branch with the new OpenSSH version
3.24
10.3_p1-r2
OpenSSH_10.3p1
included from point release 3.24.4
3.23
10.2_p1-r1
OpenSSH_10.2p1
included from point release 3.23.8
3.22
10.0_p1-r11
OpenSSH_10.0p1
included from point release 3.22.8
3.21
9.9_p2-r1
OpenSSH_9.9p2
included from point release 3.21.10. Support for 3.21 ended on Nov 1, 2026
3.20
9.7_p1-r6
OpenSSH_9.7p1
no regular support, fix provided anyway
3.19
9.6_p1-r3
OpenSSH_9.6p1
no regular support, fix provided anyway
3.18
9.3_p2-r4
OpenSSH_9.3p2
no regular support, fix provided anyway
3.17
9.1_p1-r7
OpenSSH_9.1p1
no regular support, fix provided anyway
3.16
9.0_p1-r6
OpenSSH_9.0p1
no regular support, fix provided anyway
The official cloud images (tiny-cloud) from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 contain the fixed package. Running instances from older images must be updated by you, or password login must be turned off. Point releases are not the same as package versions: whether a system has the fix is shown by apk info -v | grep '^openssh'. sshd -V exists since OpenSSH 9.2; on older systems the version appears in the usage output.
Other platforms and products
Assessment of other platforms based on vendor statements, package sources and analyses (as of Nov 6, 2026)
Platform
Assessment
Note
Debian, Ubuntu, RHEL, Fedora, SUSE, Amazon Linux
not affected (glibc)
glibc and PAM. According to OpenSSH, the flaw does not exist on Linux systems with glibc or on systems that check passwords via PAM. Red Hat explicitly states that its products are not affected.
OpenBSD, FreeBSD, macOS, Windows
not affected
According to OpenSSH, the flaw only affects Linux.
Dropbear
not affected
Separate SSH implementation, the default SSH server of OpenWrt and many devices.
OpenWrt with the openssh-server package
possible
The package is built without PAM. Affected if it is installed and the other preconditions are met. The master branch of the package feed already carries 10.6p2; the openssh-server-pam variant checks via PAM.
Buildroot, Yocto, custom firmware
possible
Affected if the firmware is built with musl and OpenSSH checks passwords without PAM. Buildroot builds OpenSSH without PAM unless Linux-PAM is selected and already carries 10.6p2 in its development tree. Ask the vendor about the status of your device.
Other musl distributions
possible
postmarketOS, Void Linux (musl), Chimera Linux and others: affected only if sshd checks passwords without PAM. Follow the respective project's guidance.
Container images with sshd
possible
Only affected if an sshd runs inside the container. Check Alpine-based images for SFTP, Git or debug access, including those with openssh-server-pam unless UsePAM yes is set explicitly. Images without sshd are not affected.
Alpine cloud images (tiny-cloud)
exposed once a password exists
Images from 3.18.11 through 3.24.3: alpine account with * and passwordless doas. Safe on first boot, vulnerable from the first $6$ hash on the machine. According to Alpine, images configured via cloud-init set PasswordAuthentication no.
Self-test: Is this system vulnerable?
Answer the questions for one SSH server. The commands in the preconditions table or the check commands give you the answers. The result appears immediately.
Exposed means: anyone who can reach the port and knows an account name can log in.
Not exploitable right now means: a precondition is missing, which can change with the next account or password.
Not affected means: the flaw cannot occur on this system.
The self-test runs entirely in your browser; nothing is sent or stored. It does not replace checking all systems or vendor guidance.
Check commands for servers and containers
These commands change nothing on your systems. Run them as root on the system you want to check, in containers via docker exec or kubectl exec. Run the last command from another machine.
# 1. C library: is there a musl loader?
ls /lib/ld-musl-*.so.1 2>/dev/null
# 2. and 3. PAM and password login per active configuration (Alpine with PAM: sshd.pam -T)
sshd -T | grep -Ei '^(usepam|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
# 4. Possible targets: accounts with exactly "*" in the password field
awk -F: '$2=="*"{print $1}' /etc/shadow
# 5. Salt donors: accounts with a password hash in passwd order; per IONIX the first one counts:# $5$/$6$ = exploitable, $2…$ (bcrypt) = before 10.6p2 even with a short password, $1$/$y$ = not
awk -F: 'NR==FNR{h[$1]=$2; next} h[$1] ~ /^\$/{print $1, substr(h[$1], 1, index(substr(h[$1], 2), "$") + 1)}' /etc/shadow /etc/passwd
# Alpine: branch and installed package version (decisive, not sshd -V)
cat /etc/alpine-release
apk info -v 2>/dev/null | grep '^openssh'
# Is the old sshd still running? "(deleted)" means: restart missing
for p in $(pidof sshd); do readlink /proc/$p/exe; done
# Logs: password logins (Alpine: /var/log/messages, otherwise auth.log or the journal)
grep 'Accepted password' /var/log/messages /var/log/auth.log 2>/dev/null
# From the outside: which authentication methods does the server offer this user?
ssh -o PreferredAuthentications=none -o PubkeyAuthentication=no -o BatchMode=yes \
-v USER@HOST 2>&1 | grep 'can continue'
If the last output contains password, the server accepts passwords for this user. A Match block can change that per user, so check the account names actually in use.
Tools · open source
The discoverer's check script and labs
In the repository oz9un/sshole, the discoverer provides a check script, a proof of concept, a lab environment with Alpine 3.24 and the patch under the MIT license. The script check.sh only reads and writes nothing. It needs root because it evaluates /etc/shadow, and reports exit code 0 for exposed, 1 for not exposed and 2 for unclear.
Limitation on Alpine:check.sh recognizes the fix only by an sshd version of 10.6p2 or later. It therefore keeps reporting patched systems on Alpine branches 3.16 to 3.24 as exposed when the other preconditions are met. There, the package version from the version table decides.
Reproduction labs: The CVE record links two more lab environments, predkambrij/sshhole-repro and leonjza/sshhole-lab.
Caution: Read third-party scripts before running them as root.
A login attempt with a long password is an access attempt on someone's account. Test only your own systems or those you have written approval for.
Successful tests leave real sessions and log entries. Coordinate them with operations and your SOC so they are not treated as an attack.
Match every finding against package version, configuration and vendor guidance.
VamiSec supports you
Analysis, recon and attack surface management
We check your systems, images and devices, evaluate the results and separate real findings from false alarms. We map your external attack surface with VamiRedteam. The agentic platform maps domains, hosts and exposed services and works only within the approved scope: with signed authorization, a hard scope boundary and a complete audit log.
A successful exploitation looks like a normal password login in the logs. sshd logs neither the password nor its length. What stands out is the context: a password login to an account that has no password at all.
sshd logs
Password login without a password
Accepted password for alpine from 203.0.113.7 port 51234 ssh2, or the same line for root, git and other key-only accounts
On Alpine in /var/log/messages, otherwise in auth.log or the journal
Failed password attempts from the same source shortly before
Logins from unknown networks to accounts that otherwise only use keys
Host
What happens after the login
doas or sudo calls by alpine or service accounts
New accounts, changes to authorized_keys, new cron jobs and services
Unknown processes and outbound connections
Port forwarding over SSH into the internal network
Network
Unusual SSH sessions
Many connections with password attempts from single sources
SSH sessions to devices that are rarely administered
Tunnels or proxy traffic over SSH connections from devices
Expect SSH brute-force tools to start trying long passwords routinely soon.
Limits of forensics: On Alpine, do not rely on last or who. According to IONIX, lastlog and classic utmp/wtmp logging are disabled in Alpine's OpenSSH build; wtmp entries only appear if the utmps services run, and only for interactive sessions. The sshd logs are what counts. If they are only stored locally, an attacker with root privileges can delete them. Collect logs centrally, and install the update even if you find nothing suspicious.
Suspect a compromise? Our CSIRT is available around the clock at csirt@vamisec.com. A compromise assessment clarifies whether attackers are already inside.
07 · Status and background
Is *sshole already being exploited?
As of , no exploitation is known. But the attack is simple, and instructions and labs are public. Expect scanning as soon as attackers have adapted their tools.
Authorities
No KEV entry, PoC confirmed
CVE-2026-123158 is not yet in the Known Exploited Vulnerabilities (KEV) catalog of the US agency CISA. The latest catalog of Nov 4, however, predates the disclosure. In its assessment of November 5, CISA records: proof of concept available, not automatable, total technical impact. Red Hat states that its products are not affected.
Security vendors
No attacks reported yet
On November 5, Detectify was not aware of any exploitation but expects scanning, because the details are public and the attack is simple. Jake Knott of watchTowr told CSO Online to expect SSH brute-forcers to try the trick by the weekend.
Exploit code
No exploit needed
Besides the check script, the discoverer published a proof of concept. It logs in with the standard SSH client or a short Python script and a 300-character password. More labs are linked in the CVE record. For defenders, this means: do not wait for reports of attacks.
Why the bug went unnoticed for ten years
None of the decisions involved was wrong on its own. musl wanted to prevent crashes in programs that do not check the result of crypt(). OpenSSH wanted to stop attackers from guessing valid user names from response times. In 2022, Alpine switched root from ! to * so that SSH keys for root work again. Only together do they create the flaw.
At the end of 2024, the musl mailing list even discussed a crash of busybox passwd with a 257-byte password, without making the connection to sshd. The flaw was only found by a test matrix across C libraries and build options, run by agent swarms.
Since OpenSSH 10.5 in August 2026, the project has reported many AI-assisted bug reports and that bugs found by AI are rediscovered independently. According to Damien Miller, this sometimes happens within hours. The consequences are shorter embargoes and more frequent releases. For operators, the time between disclosure and attack shrinks. If you want to react in hours rather than weeks, you need a current inventory and rehearsed processes.
Timeline
musl makes crypt() return * on errors and limits SHA-crypt to 256 bytes.
OpenSSH mitigates CVE-2016-6210 with the borrowed salt from pick_salt(), shipped from 7.3p1. The flaw is born.
Alpine 3.16 switches root from ! to * so that SSH keys for root work again.
On the musl mailing list, the crash of busybox passwd with 257 bytes is noticed, the link to sshd is not.
Özgün Kültekin finds the flaw with a test matrix across C libraries and build options and reports it to the OpenSSH project. According to the discoverer, a patch is ready within an hour.
Alpine and musl are notified; the fix is committed to the OpenSSH source.
OpenSSH 10.6p2 is released; Alpine ships patched packages for 3.16 to 3.24 and edge plus point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4. The discoverer's write-up goes online, MITRE publishes the CVE ID.
Broad coverage in the trade press. No exploitation known as of November 6.
08 · VamiSec exposure check
We check at short notice whether *sshole affects you
You decide how deep we look: from the outside only, without access to your environment, or additionally from the inside with read-only checks on servers, images and devices. The result is a prioritized list of where to act first.
Option A · from the outside
Black-box check
We look at your environment the way an attacker sees it from the internet. You do not need to give us any access.
With recon and attack surface management by VamiRedteam, we map your reachable SSH services, starting from your domains and IP ranges
For each service we determine, without logging in, which methods it offers, and flag services that accept passwords
Banners and fingerprints provide hints for musl-based systems such as Alpine, OpenWrt or embedded firmware
Login attempts with long passwords only after separate written approval and only on your own systems
Result: list of your reachable SSH services with password login and a risk rating. From the outside you get indications, but no certainty about accounts and package versions.
Option B · from the inside
Server, image and account check
We check read-only on your systems, without changing anything, and match the results against the fixed package versions.
Checks of Linux servers for C library, PAM, password login, accounts with *, salt donors, package version and sshd restart
Container images in registries and running pods with sshd, plus golden images and cloud templates
For cloud accounts, optionally an agentless inventory of VMs and images with Wiz. VamiSec is a member of the Wiz Partner Alliance
Comparison with the guidance from OpenSSH, Alpine and your vendors
Result: a reliable inventory of which systems are exposed, which are protected only by configuration and which are patched.
Recommended · combined
Outside and inside together
The combination answers the decisive question: which exposed systems can an attacker actually reach?
Outside view and inventory are brought together
Attack paths from the internet to accounts with doas or sudo rights
Prioritized action plan with order, interim protection and evidence for audits
Check after patching that all systems have the fix and sshd was restarted
Result: a reliable basis for decisions by IT, the CISO and management.
01 · Kick-off
Define the scope
In 30 minutes we clarify domains, networks, cloud providers, images, devices and your priorities.
02 · Approval
Authorize in writing
You approve the scope in writing. Without approval we test nothing.
03 · Check
Outside and inside view
We run the agreed checks and report exposed systems immediately.
04 · Result
Report and action plan
You receive a management summary, the technical findings list and the order of actions.
For device manufacturers
We check firmware based on OpenWrt, Buildroot or Yocto: C library, OpenSSH build options, default accounts and password fields
We test devices as part of our IoT pentests and document findings and fixes
We support vulnerability handling and reporting under the Cyber Resilience Act
How we work
We work only within the approved scope and agree on test windows with you. Systems that service providers run for you are tested actively only with their consent
Login attempts with long passwords only after separate written approval and coordinated with your operations and SOC
Confidentiality is covered by an NDA upfront, processing of test data by a data processing agreement where needed
If there are signs of a compromise, we bring in our CSIRT immediately on request
Request an exposure check
Book a call directly or write to contact@vamisec.com. We reply within 24 hours. Feel free to include domains, networks, cloud providers and device types so we can estimate the scope right away.
In Germany and the EU, an unexploited vulnerability alone does not trigger a reporting duty. That changes once it has been exploited in your environment. Manufacturers that ship OpenSSH in their own products must also report as soon as there are reliable indications of active exploitation. Deadlines start when you become aware of the incident, not when the CVE is published. This overview is guidance, not legal advice.
NIS2
Essential and important entities
Handling and patching vulnerabilities is part of the risk management NIS2 requires. You must report a significant incident, such as successful unauthorized access that can severely disrupt operations. Then: early warning within 24 hours, notification within 72 hours, final report one month after the notification.
GDPR
When personal data is involved
If an attacker had SSH access to systems with personal data, notify the supervisory authority without undue delay and, where feasible, within 72 hours unless a risk is unlikely. If the risk is high, inform the data subjects without undue delay. Every personal data breach must be documented.
Cyber Resilience Act
Manufacturers that ship OpenSSH in products
Since September 11, 2026, manufacturers must report actively exploited vulnerabilities in their products through ENISA's reporting platform, including for products already sold. If *sshole were actively exploited, this would apply, for example, to routers, gateways and devices with OpenSSH on musl without PAM. Deadlines: 24 hours, 72 hours and a final report 14 days after a fix is available. From December 11, 2027, the vulnerability handling obligations for new products apply as well.
DORA
Financial entities
Banks, insurers and other financial entities report under DORA to their supervisor. A successful, malicious access is a key criterion for a major ICT-related incident there. The initial notification is due within 4 hours of classification, at the latest 24 hours after becoming aware.
A blocked login attempt is usually not a reportable incident, at most a near miss. Voluntary reports, including anonymous ones, to the national CSIRT or authority are still possible. More: NIS2, Cyber Resilience Act, DORA.
10 · FAQ
Frequently asked questions about *sshole
What is *sshole?
*sshole is the name for CVE-2026-123158, a flaw in the OpenSSH server sshd on Linux systems with the musl C library that check passwords without PAM. For accounts whose password field contains only an asterisk, sshd accepts any password of 257 to 1,024 bytes there. The flaw is fixed in OpenSSH 10.6p2 of November 5, 2026 and in backported distribution packages.
Why is the flaw called *sshole?
The name plays on the asterisk at the heart of it: the * in the password field of /etc/shadow that marks an account without a usable password. The discoverer Özgün Kültekin publishes the write-up at sshhole.com, and the press also uses sshole and sshhole. It always refers to CVE-2026-123158.
Am I affected by *sshole?
Only if five things come together: sshd runs on musl, checks passwords without PAM, password login is enabled, there is an account with exactly * in the password field, and another local account has a password hash, typically SHA starting with $5$ or $6$. This is typical for Alpine Linux with the openssh-server package. The self-test on this page evaluates your answers immediately.
Are Debian, Ubuntu or Red Hat affected?
No. These distributions use glibc and check passwords via PAM. According to OpenSSH, the flaw does not exist on Linux systems with glibc or on systems that use PAM for password authentication. Red Hat explicitly states that its products are not affected.
Is an Alpine container automatically affected?
No. A container is only affected if an sshd runs inside it and the other preconditions are met. Most Alpine-based images contain no SSH server. Do check images that deliberately offer SSH, for example for SFTP, Git or debug access.
Is an account with * in the password field locked?
Not in OpenSSH's sense. A * means there is no usable password; login with an SSH key remains possible. Locked in OpenSSH's sense are accounts whose password field starts with !. They allow neither password nor key and are not affected by *sshole. Replacing a * with ! therefore also blocks key access.
Can an attacker become root?
Usually not directly: on Alpine, root does carry an asterisk, but the default PermitRootLogin prohibit-password protects it from password login. Other accounts are still a way in. In Alpine's official cloud images from 3.18.11 through 3.24.3, the alpine account has an asterisk and may use doas without a password. As soon as any account on the machine has a password, that path leads to root.
Which versions are safe?
OpenSSH 10.6p2 and later. On Alpine, the openssh packages 10.6_p2-r0 (edge), 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17) and 9.0_p1-r6 (3.16) contain the fix. On the stable branches, sshd keeps reporting the old OpenSSH version; the package version decides.
Is PasswordAuthentication no enough as protection?
Yes, as an interim measure. Without password login, the flaw cannot be exploited. Make sure no Match block re-enables passwords for individual users, and note that Alpine before 3.19 does not read drop-in files. Test key login first and install the update anyway.
Do I need to restart sshd after the update?
Yes. According to Alpine, a package update does not replace the running sshd. Restart sshd, on Alpine with rc-service sshd restart, and redeploy containers with rebuilt images. If readlink /proc/PID/exe shows "(deleted)" for the sshd process, the old binary is still running.
Why does sshd report the old version after the update?
Because Alpine backported the fix to its stable branches without changing the OpenSSH version. On Alpine 3.24, sshd with the fix still reports OpenSSH_10.3p1. Whether the fix is installed is shown by the package version, such as openssh-server-10.3_p1-r2. Check scripts that only evaluate the sshd version therefore wrongly report patched Alpine systems as exposed.
Is *sshole already being actively exploited?
As of November 6, 2026, no exploitation is known, and CISA does not list the flaw in its KEV catalog so far. But the attack needs no exploit technique, a proof of concept is public, and experts expect scanning soon. Treat reachable systems as if they were being attacked.
Is there a scanner or proof of concept?
Yes. In the repository oz9un/sshole, the discoverer provides a read-only check script, a proof of concept, a lab environment and the patch. The check script recognizes the fix only by the sshd version and therefore keeps reporting patched Alpine branches as exposed. Run login attempts with long passwords only on your own or approved systems.
Are routers and IoT devices affected?
Possibly. OpenWrt uses musl, but its default SSH server Dropbear is not affected. The optional openssh-server package, built without PAM, can be. Firmware from Buildroot or Yocto is affected if it is built with musl and OpenSSH checks passwords without PAM. Ask your vendors about the status of their devices.
What does AI have to do with *sshole?
According to the write-up, the discoverer found the flaw with agent swarms that ran around 17,600 unusual login attempts against differently built sshd variants. The OpenSSH project has been reporting many AI-assisted bug reports for months. According to Damien Miller, AI agents sometimes rediscover reported bugs within hours, so the team now considers long embargo periods dangerous. Patches come faster, and the time until the first attacks gets shorter.
Do I have to report *sshole?
The vulnerability alone is not reportable. A reporting duty arises with a significant incident under NIS2, a personal data breach under the GDPR, a major ICT-related incident under DORA, or, for manufacturers, an actively exploited vulnerability in their own product under the Cyber Resilience Act.
How does the VamiSec exposure check work?
After a 30-minute kick-off and your written approval, we check from the outside with VamiRedteam which of your SSH services are reachable and accept passwords. On request, we also check from the inside, read-only and without changes, which servers, images and devices meet the preconditions. You receive a prioritized findings list and an action plan. We report exposed systems immediately.
11 · Sources
Primary sources and analyses
This page summarizes the publications in our own words. The original sources are authoritative. We update the page as the situation changes.
