{"id":3100,"date":"2026-11-09T00:43:40","date_gmt":"2026-11-09T08:43:40","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=3100"},"modified":"2026-11-09T00:50:22","modified_gmt":"2026-11-09T08:50:22","slug":"emerging-threat-cve-2026-123158-openssh-password-authentication-bypass-on-musl-linux","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/emerging-threat-cve-2026-123158-openssh-password-authentication-bypass-on-musl-linux\/","title":{"rendered":"Emerging Threat: (CVE-2026-123158) OpenSSH Password Authentication Bypass on musl Linux"},"content":{"rendered":"
\n
\"\"
Sample of assets potentially affected by the OpenSSH sshhole vulnerability, identified by the CyCognito Platform<\/em><\/em><\/figcaption><\/figure>\n<\/div>\n\n\n

What is CVE-2026-123158?<\/strong><\/h2>\n\n\n\n

CVE-2026-123158, also referred to as “sshhole,” is a password authentication bypass in OpenSSH’s sshd when it is built against the musl C library and without PAM. The flaw stems from how sshd handles the result of musl’s crypt() function when it is given an overlong password.<\/p>\n\n\n\n

The vulnerability carries a CVSS v3.1 base score of 8.1 (High).<\/p>\n\n\n\n

Exploitation is pre-authentication. An attacker who can reach sshd over the network can log in as an affected account without knowing its password, and public reproduction labs are available. Where the account can escalate privileges, as with the default user on some cloud images, this can lead to full control of the host.<\/p>\n\n\n\n

Several conditions must line up. Password authentication must be enabled, which is the default. The target account’s password field in \/etc\/shadow must be exactly *, and at least one other local account must hold a SHA-crypt (5 or 6) hash. Accounts locked with ! are not affected.<\/p>\n\n\n\n

What assets are affected by CVE-2026-123158?<\/strong><\/h2>\n\n\n\n

The flaw affects OpenSSH versions before 10.6p2 when built with musl and without PAM, or with UsePAM no. Alpine Linux is the primary affected platform, because its openssh-server package is built this way by default. Other musl-based systems, such as OpenWrt or Buildroot images, may also be exposed depending on how OpenSSH was built.<\/p>\n\n\n\n

In practice, an affected asset is a lightweight Linux host or appliance exposing TCP\/22 to the internet: Alpine-based cloud instances, minimal virtual machines, embedded devices, and containers that run sshd with password logins enabled. Official Alpine cloud images ship a default user whose password field is *, which makes that account a direct target once any other account has a password set.<\/p>\n\n\n\n

Distributions built on glibc and PAM are outside the affected configuration. Debian, Ubuntu, Fedora, and Red Hat Enterprise Linux are not affected, and Red Hat lists all of its builds as not affected.<\/p>\n\n\n\n

What does our data show about exposure patterns?<\/strong><\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Exposure in this set is led by Consumer Discretionary at 20.7% of observed assets, with Communication Services contributing 14.9%. The set reflects assets observed running OpenSSH in the affected version range, or with an undetermined version, where the host operating system was not identified. It is not a list of confirmed vulnerable hosts. Roughly three quarters of the set matched on version alone, the remainder could not be versioned, and a dedicated CyCognito active test did not confirm any of these assets as exploitable.<\/p>\n\n\n\n

Consumer Discretionary and Communication Services organizations tend to run large, distributed web estates: hotel and travel properties, consumer brands, publishing and broadcast sites, and the hosting behind them. Many of these servers sit with agencies, regional teams, or acquired business units, which makes SSH configuration harder to standardize. A small share of organizations also accounts for more than half of the observed assets, so a single large estate can lift an entire sector’s share.<\/p>\n\n\n\n

The broader pattern points to a visibility problem rather than a concentration of vulnerable builds. Version matching cannot tell a musl build from a glibc build, and Alpine’s patched packages keep their older version numbers, so version-based inventories will both overstate and misstate exposure to this flaw. Defenders need build-level and configuration-level detail, such as the C library, the PAM setting, and whether password logins are enabled, to know which externally reachable SSH services are actually at risk.<\/p>\n\n\n\n

Are fixes available?<\/strong><\/h2>\n\n\n\n

Yes. OpenSSH 10.6p2 fixes the vulnerability upstream by rejecting stored password hashes that are too short to be valid. Alpine released patched openssh packages for edge and for its supported branches from 3.16 through 3.24.<\/p>\n\n\n\n

Alpine backported the fix rather than moving every branch to 10.6p2. Patched packages therefore keep their original version numbers, for example 10.3_p1-r2 on Alpine 3.24 and 10.0_p1-r11 on Alpine 3.22. A host that reports an older OpenSSH version may already be patched, so defenders should check the package release, not only the upstream version string.<\/p>\n\n\n\n

Updating the package does not replace the running daemon. sshd must be restarted for the fix to take effect. For other musl-based systems, defenders should confirm with their vendor or image maintainer whether a fixed build is available rather than assuming one is.<\/p>\n\n\n\n

Are there any other recommended actions to take?<\/strong><\/h2>\n\n\n\n

Until patching is confirmed, defenders should:<\/p>\n\n\n\n