sshd<\/code>. Its CVSS v3.1 base score is 8.1 (High).<\/p>\nThe vulnerability affects specific Linux configurations using musl without PAM. Password authentication must also be enabled, and particular account conditions must exist.<\/p>\n
Alpine Linux’s default openssh-server<\/code> package is built without PAM. Therefore, Alpine systems with the required account and authentication settings can be vulnerable.<\/p>\n\u00d6zg\u00fcn K\u00fcltekin of Wakefield discovered the vulnerability and named it SSHole. Unlike memory-corruption vulnerabilities, SSHole results from two existing implementation behaviors: one in OpenSSH and another in musl.<\/p>\n
SSHole Vulnerability Details<\/h2>\n
\n\n\nDetail<\/span><\/b>\u00a0<\/span><\/td>\n Information<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n\nCVE<\/span>\u00a0<\/span><\/td>\n CVE-2026-123158 (SSHole)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nProduct<\/span>\u00a0<\/span><\/td>\n Portable OpenSSH sshd<\/code> before 10.6p2 on Linux using musl without PAM, unless patched by the distribution<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nVulnerability type<\/span>\u00a0<\/span><\/td>\n Password authentication bypass<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nCVSS<\/span>\u00a0<\/span><\/td>\n v3.1 base score 8.1 (High)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nAttack prerequisite<\/span>\u00a0<\/span><\/td>\n Reachable SSH service, password authentication enabled, affected account, and required fallback hash selection<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nPotential impact<\/span>\u00a0<\/span><\/td>\n Unauthorized account access, potentially including indirect root access on affected Alpine cloud images<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nFixed version<\/span>\u00a0<\/span><\/td>\n OpenSSH 10.6p2; patched Alpine packages back to 3.16<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\nKEV status<\/span>\u00a0<\/span><\/td>\n Not listed in CISA’s KEV Catalog as of November 9, 2026. However, Previdian has included the vulnerability in its own KEV feed based on observed exploitation attempts<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nHow Does SSHole CVE-2026-123158 Exploit musl’s crypt()?<\/h2>\n
SSHole exploits how musl handles password-hashing errors. When processing oversized passwords with valid SHA-256-crypt or SHA-512-crypt settings, musl returns *<\/code>.<\/p>\nWithout PAM, sshd<\/code> hashes submitted passwords using crypt()<\/code> and compares the result against the stored password field for local accounts. Consequently, musl’s error response can match an existing *<\/code> shadow entry.<\/p>\nAlpine also identifies directory-service identities resolved through musl-nscd<\/code> without local shadow entries as potentially affected.<\/p>\nOpenSSH’s 2016 Authentication-Timing Workaround<\/h3>\n
In 2016, OpenSSH introduced fallback password hashing to mitigate username-enumeration timing differences associated with CVE-2016-6210.<\/p>\n
For nonexistent accounts, sshd<\/code> enumerates system account entries using setpwent()<\/code> and getpwent()<\/code>. It selects the salt from the first account whose stored password field begins with $<\/code> and contains another $<\/code> delimiter. This is a structural check, not full cryptographic validation of the stored hash.<\/p>\nThis fallback also affects real accounts with *<\/code> password fields. For SSHole, the selected account’s hash must use SHA-256-crypt ($5$<\/code>) or SHA-512-crypt ($6$<\/code>).<\/p>\nmusl’s crypt() Error Handling<\/h3>\n
Since 2012, musl has rejected SHA-256-crypt and SHA-512-crypt password inputs longer than 256 bytes.<\/p>\n
When both values are *<\/code>, the comparison can succeed and allow authentication.<\/p>\nAn attacker who knows the target username can submit a password between 257 and 1,024 bytes. The failed hash returns *<\/code>, potentially matching the account’s shadow entry.<\/p>\nAlpine’s advisory describes exploitation through one SSH connection without connection retries. However, an independent source-level reproduction found that the first password attempt failed. The second succeeded within the same connection.<\/p>\n
K\u00fcltekin tested sshd<\/code> builds across glibc and musl, with and without PAM. The tests involved approximately 17,600 unusual login attempts. Only the tested musl builds without PAM accepted logins that should have been rejected.<\/p>\nThese implementation behaviors explain how SSHole works. However, actual exposure depends on how organizations deploy and configure OpenSSH across their Linux systems.<\/p>\n
Which Alpine and musl Systems Are Vulnerable to SSHole?<\/h2>\n
SSHole affects specific OpenSSH configurations rather than every Linux system using musl. Administrators should evaluate the SSH configuration, account database, and password-hashing behavior together.<\/p>\n
Alpine Linux<\/h3>\n
Alpine’s default openssh-server<\/code> package is built without PAM. Its openssh-server-pam<\/code> variant is affected when UsePAM no<\/code> is configured.<\/p>\nAn Alpine host is potentially vulnerable when password authentication is enabled and the target is an account with *<\/code> in its shadow password field or an affected directory-service identity resolved through musl-nscd<\/code> without a shadow entry.<\/p>\nAlso verify that OpenSSH’s selected fallback hash meets the $5$<\/code> or $6$<\/code> requirement.<\/p>\nAlpine Cloud Images<\/h3>\n
Official Alpine tiny-cloud images (qcow2<\/code>, VHD<\/code>, and AMI<\/code>) from versions 3.18.11 through 3.24.3 include an alpine user with a *<\/code> password field and passwordless doas<\/code>.<\/p>\nThese images are safe on first boot. They become exploitable when another local account introduces a SHA-512-crypt ($6$<\/code>) password hash. This can happen when an administrator sets a console password or user-data adds an account with hashed_passwd<\/code>.<\/p>\nThe default PermitRootLogin prohibit-password<\/code> setting blocks direct root password authentication over SSH. However, attackers who authenticate as the alpine user can still obtain root privileges through its passwordless doas<\/code> permissions.<\/p>\nCloud images configured through cloud-init are not affected by default because cloud-init writes PasswordAuthentication no<\/code>.<\/p>\nOther musl-Based Systems<\/h3>\n
OpenWrt, Buildroot, and Yocto images may also be exposed, depending on their OpenSSH and libc configurations.<\/p>\n
OpenWrt uses Dropbear by default, which is not affected. However, its musl-based builds can use the openssh-server<\/code> package without PAM or the separate openssh-server-pam<\/code> variant.<\/p>\nEvaluate the installed package, libc implementation, and effective PAM configuration before determining exposure.<\/p>\n
Container Images<\/h3>\n
Containers running a reachable OpenSSH daemon built with musl and without PAM are potentially exposed.<\/p>\n
However, exploitation also requires password authentication to be enabled, a target account with a *<\/code> password field or an affected directory-service identity, and at least one local account with a SHA-256-crypt ($5$<\/code>) or SHA-512-crypt ($6$<\/code>) password hash. Containers without a reachable SSH service are not exposed through this attack path.<\/p>\nSystems Not Affected<\/h3>\n
The following configurations are outside the documented vulnerable scope:<\/p>\n
\n- Standard glibc-based Debian, Ubuntu, and Fedora installations.<\/li>\n
- OpenSSH configurations using PAM with
UsePAM yes<\/code>.<\/li>\n- Dropbear-based SSH services.<\/li>\n
- Native OpenBSD systems.<\/li>\n<\/ul>\n
What Did Previdian and GreyNoise Observe After Disclosure?<\/h2>\n
Previdian reported its first observed exploitation attempt approximately eight hours after CVE publication<\/a>.<\/p>\nPrevidian’s founder told The Hacker News that the company had confirmed root access on an Alpine Linux honeypot.<\/p>\n
Separately, Previdian’s public sensor telemetry documents observed attempts rather than independently establishing successful exploitation.<\/p>\n
The founder also reported that activity from the source IP involved oversized passwords and non-interactive SSH sessions. The sessions executed commands such as id<\/code>, uname<\/code>, and hostname<\/code>.<\/p>\nInitial reporting counted eight attempts from one Japan-based IP address. By November 9, Previdian had recorded 20 attempts from 13 IP addresses across nine countries. Its four sensors observed this activity.<\/p>\n
What Did GreyNoise Confirm?<\/h3>\n
Observed activity included root-level command execution and unauthorized modifications to SSH authorized_keys<\/code> files.<\/p>\nOne attacker also uploaded a Python-based C2 agent and attempted to enroll it. However, enrollment failed, and the agent received no tasks.<\/p>\n
Public reporting has not established successful data exfiltration or lateral movement to other systems.<\/p>\n
Separately, Previdian cautions that available GitHub proof-of-concept samples are unverified and may contain malware.<\/p>\n
How to Patch SSHole CVE-2026-123158<\/h2>\n
The primary remediation is upgrading to OpenSSH 10.6p2 or an equivalent patched distribution package.<\/p>\n
Update Alpine Packages<\/h3>\n
Alpine’s security advisory<\/a> lists fixed packages for:<\/p>\n
\n\n\nAlpine branch<\/span><\/b>\u00a0<\/span><\/td>\n Fixed release<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n\n3.21<\/span>\u00a0<\/span><\/td>\n 3.21.10<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\n3.22<\/span>\u00a0<\/span><\/td>\n 3.22.8<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\n3.23<\/span>\u00a0<\/span><\/td>\n 3.23.8<\/span>\u00a0<\/span><\/td>\n<\/tr>\n\n3.24<\/span>\u00a0<\/span><\/td>\n 3.24.4<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nAlpine also published fixes for older branches, extending back to 3.16.<\/p>\n
Check the advisory for the exact package version applicable to each branch. Patched Alpine packages may carry version numbers older than upstream OpenSSH 10.6p2.<\/p>\n
Consequently, scanners that compare only against the upstream version may incorrectly flag patched installations.<\/p>\n
Restart Running SSH Services<\/h3>\n
On Alpine Linux, installing the OpenSSH update does not automatically restart a running sshd<\/code> process. Restart the service after upgrading to ensure the patched binary is running. On other distributions, verify whether the package update restarted the service.<\/p>\nRebuild Container Images<\/h3>\n
Rebuild and redeploy container images containing vulnerable OpenSSH packages.<\/p>\n
Alpine releases before 3.16 have no fixed packages listed in the advisory. Administrators should migrate to a release containing the fix or rebuild with patched OpenSSH 10.6p2 or an equivalent backport.<\/p>\n
Apply Interim Mitigations<\/h3>\n
OpenSSH developer Damien Miller advised disabling SSH or setting PasswordAuthentication no<\/code> on affected systems until they are patched.<\/p>\nAfter changing the SSH configuration, restart sshd<\/code> to apply the setting.<\/p>\nChecking Alpine Hosts for Signs of an SSHole Login<\/h2>\n
Patching addresses the vulnerability, but administrators should also investigate previously exposed hosts.<\/p>\n
On unpatched Alpine hosts, search \/var\/log\/messages<\/code> for sshd<\/code> entries containing Accepted password for.<\/p>\nPay particular attention to accounts intended for key-based authentication only, including alpine and other restricted accounts. Also review root authentication where PermitRootLogin yes<\/code> is configured. The default PermitRootLogin prohibit-password<\/code> setting blocks direct root password authentication, although attackers may still obtain indirect root privileges through accounts with passwordless doas<\/code> permissions.<\/p>\nOn other affected distributions, inspect configured authentication logs or the system journal for equivalent events.<\/p>\n
Also review:<\/p>\n
\ndoas<\/code> activity and unexpected privilege escalation.<\/li>\n- Recently created user accounts.<\/li>\n
- Changes to
authorized_keys<\/code> files.<\/li>\n- Unexplained successful password-authentication events.<\/li>\n<\/ul>\n
If unauthorized access cannot be ruled out, treat the host as potentially compromised and investigate accordingly.<\/p>\n
These investigation requirements also highlight the importance of understanding which Linux distributions fall outside an organization’s automated patch-management coverage.<\/p>\n\n \n \n \n ![\"Hexnode-UEM-for-Patch-Management-300x225\"](\"https:\/\/cdn.hexnode.com\/threat-watch\/wp-content\/uploads\/2026\/08\/Hexnode-UEM-for-Patch-Management-300x225-1.webp?format=webp\" "\\"Hexnode-UEM-for-Patch-Management-300x225\\"")
\n <\/div>\n <\/div>\n \n \n Featured resource\n <\/h5>\n \n Simplify Patch Management with Hexnode UEM\n <\/h4>\n
\n Explore how Hexnode UEM helps IT teams monitor patch status and manage manual and automated updates across supported Linux distributions.\n <\/p>\n \n Download the One-pager\n