OpenSSH "*sshole" auth bypass (CVE-2026-123158): oversized passwords unlock no-password accounts on musl/Alpine; fixed in 10.6p2

Linha do tempo

1. thehackernews.com ↗ · pub. 05/11/2026 13:42 · coletado 05/11 20:00

   OpenSSH 10.6p2 Fixes Critical Auth Bypass Letting Long Passwords Unlock No-Password Accounts on musl/Alpine Systems

   ler a análise desta fonte ocultar

   OpenSSH released version 10.6p2 on November 5, 2026 to fix an authentication bypass that lets a remote attacker log in to passwordless accounts, such as SSH key-only users, on Alpine Linux servers running the standard openssh-server package. The attacker needs network access to the SSH port, a valid account name, and a password between 257 and 1,024 bytes long; no password guessing beyond that length requirement is needed, and the attack succeeds on the first try. Damien Miller of the OpenSSH project rated the flaw critical and urged affected administrators to disable password authentication or SSH immediately, while noting that no exploitation has been reported in the wild. Independent reporting later tied the bug to CVE-2026-123158, which CVE/NVD records rate CVSS 3.1 8.1 (High) rather than critical, a discrepancy noted under Conflicting Reports below. Alpine Linux published fixed packages for every supported branch, including releases already past end-of-support.

   Technical Details

   The issue arises only when sshd checks passwords itself instead of through PAM, with password logins enabled and at least one other local account on the machine holding a $5$ or $6$ password hash; Alpine's default openssh-server package is built without PAM and has password logins on by default. Passwordless accounts on Alpine store * in the shadow password field, and because that value is too short to contain a salt, sshd borrows the salt from another account's real hash — a behavior introduced to fix CVE-2016-6210 in 2016. On musl libc, the crypt() function refuses to hash passwords longer than 256 bytes and returns * as an error marker; when an attacker submits a password between 257 and 1,024 bytes (sshd's own cap), musl's * error output matches the stored * for the passwordless account, and sshd accepts the login. Vulnerable passwordless accounts on Alpine can include key-only users, directory-service accounts reached via musl-nscd, root (shipped as root:* since Alpine 3.16), and the alpine user in official tiny-cloud images; root logins are normally blocked by the default PermitRootLogin prohibit-password, but tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas, allowing privilege escalation to root once a $6$ hash exists on the system. The flaw was reported by Özgün Kültekin of Wakefield, who also flagged musl-based OpenWrt, Buildroot and Yocto as systems to check, though OpenWrt's default Dropbear SSH server is not affected.

   Fix Details

   OpenSSH 10.6p2 changes sshd to refuse a credential match when the stored password field is shorter than four characters, which OpenSSH describes as a workaround since the root cause lies in musl rather than sshd itself. Alpine backported equivalent patches to every branch from 3.16 through edge; point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already ship the fixed package. OpenSSH's maintainers said they compressed the usual disclosure timeline, shipping the fix the day after learning of the issue, because long embargoes are now seen as helping attackers given that AI agents can rediscover the same bugs within hours.

   Remediation

   On Alpine, run apk upgrade -U -a and then restart sshd with rc-service sshd restart, since a package upgrade alone does not restart the running service. Systems that cannot update immediately should set PasswordAuthentication no (after confirming SSH key login works), validate the configuration with sshd -t, and restart sshd; administrators should verify the setting took effect with sshd -T | grep -i passwordauthentication. Operators should review /var/log/messages for Accepted password log lines tied to accounts expected to have no password, and treat any such match as a likely compromise, additionally reviewing doas usage, newly created users, and authorized keys files.

   Conflicting Reports

   The article, citing OpenSSH's own description, calls the flaw critical. The assigned CVE record, CVE-2026-123158, rates it CVSS 3.1 8.1 (High) (ox.security, securityboulevard.com, ionix.io), reflecting the specific prerequisites (musl without PAM, password logins enabled, another account with a hash present).

2. blog.checkpoint.com ↗ · pub. 05/11/2026 17:56 · coletado 05/11 19:00

   Critical OpenSSH musl crypt() bypass (CVE-2026-123158) lets attackers skip password auth on Alpine Linux

   ler a análise desta fonte ocultar

   OpenSSH released version 10.6p2 on November 5, 2026, fixing a critical password-authentication bypass tracked as CVE-2026-123158, dubbed sshole. On affected systems, anyone who can reach the SSH port can log in without knowing a password by sending an overly long password string.

   The flaw only hits Linux systems built against musl libc running sshd without Pluggable Authentication Modules (PAM) — the default configuration of Alpine Linux's openssh-server package. When PAM is disabled, sshd hashes the submitted password with crypt() and compares it to the stored shadow field; musl's crypt() returns an asterisk (*) as an error for any input longer than 256 bytes, and accounts with no password set also store * in that field, so a password between 257 and 1,024 bytes "matches" and authentication succeeds. The account targeted must have no password set (e.g., key-only users or the alpine user in cloud images), PasswordAuthentication must be enabled (the OpenSSH default), and at least one other active local account must hold a real $5$/$6$ password hash, since sshd borrows that account's salt. Check Point Software's testing found the second account must be active, not merely hold a stored hash. glibc-based Linux distributions, non-Linux systems, and any system using PAM are not affected, according to OpenSSH developer Damien Miller. Root is protected by the default PermitRootLogin prohibit-password setting, though any compromised account with sudo/doas rights can still escalate.

   Technical Details

   The OpenSSH version is visible in the SSH banner and whether password authentication is offered can be checked remotely, but musl usage, PAM status, and account/password states require host-level inspection. Version strings can mislead: Alpine's patched packages retain older version numbers (e.g., 10.3_p1-r2 on Alpine 3.24), so a fixed host can appear vulnerable to naive scanners. As of the article's publication, no CVE had been assigned yet, though subsequent reporting confirmed CVE-2026-123158 with a CVSS score of 8.1 (High) (ox.security). According to the Alpine Linux advisory, the attack requires only a single connection, works reliably, and needs no retries.

   Fix Details

   OpenSSH 10.6p2 prevents the bypass by rejecting stored password hashes that are too short to represent a valid hash (ox.security). Alpine Linux backported fixes across all supported branches: edge (10.6_p2-r0), 3.24 (10.3_p1-r2), 3.23 (10.2_p1-r1), and 3.22 (10.0_p1-r11), with patches extending back to branch 3.16 (kucoin.com). The OpenSSH team shipped the fix roughly one day after the bug was reported, citing the risk that AI tools can now rediscover vulnerabilities within hours, making long embargoes counterproductive.

   Remediation

   Apply the Alpine package upgrade (apk upgrade) and restart sshd, since the package upgrade alone does not restart the running daemon. Where patching is not immediately possible, set PasswordAuthentication no. Defenders should search logs for "Accepted password for" events tied to accounts with no password set, and treat any such match as a likely compromise. Organizations should prioritize internet-facing Alpine-based SSH servers and containers that accept password authentication, since CVE-based scanning alone may miss this issue given its late CVE assignment.

3. theregister.com ↗ · pub. 05/11/2026 15:29 · coletado 05/11 16:00

   "*sshole" Bug Lets Attackers Gain Root on musl-based Linux via Oversized SSH Passwords

   This article adds historical context tracing the vulnerability's root cause to BSD Unix conventions dating to 1980 and Bill Joy's work, clarifies that musl's SHA-512 password hashing grows slower with longer inputs (creating a secondary denial-of-service risk capped at 256 bytes), and details the mechanics of the 2016 OpenSSH username-enumeration fix that underlies the bypass. It also notes that Kültekin's writeup includes a CLI command defenders can use to detect whether a no-password account has recently accepted a password login, reinforcing that no in-the-wild exploitation has been observed.

   ler a análise desta fonte ocultar

   This article adds historical context tracing the vulnerability's root cause to BSD Unix conventions dating to 1980 and Bill Joy's work, clarifies that musl's SHA-512 password hashing grows slower with longer inputs (creating a secondary denial-of-service risk capped at 256 bytes), and details the mechanics of the 2016 OpenSSH username-enumeration fix that underlies the bypass. It also notes that Kültekin's writeup includes a CLI command defenders can use to detect whether a no-password account has recently accepted a password login, reinforcing that no in-the-wild exploitation has been observed.

   A vulnerability nicknamed *sshole, discovered by researcher Özgün Kültekin, allows an attacker to gain root or other restricted access on certain Linux systems by submitting an SSH password longer than 256 bytes. The flaw affects systems using musl libc instead of glibc, running OpenSSH's sshd without PAM and with password authentication enabled, where at least one account has a valid password hash and the targeted account (such as root, a key-only user, or an LDAP user) has an asterisk in its password field. Musl libc is widely used in embedded Linux and is the standard C library for Alpine Linux, including Alpine's official AWS and Azure cloud images, meaning some cloud deployments could be exposed depending on configuration.

   Technical Details

   The root cause traces back to musl's crypt() function, which returns the single character "*" instead of NULL on certain hashing failures, combined with the BSD Unix-era convention (dating to Bill Joy's 1980 work on BSD) of placing an asterisk in /etc/passwd or /etc/shadow to disable password logins for an account. Musl also caps passwords at 256 bytes for its SHA-512-based hashing, which grows slower as password length increases, creating a secondary denial-of-service risk if an attacker floods a server with very long passwords. In 2016, OpenSSH introduced dummy password hashing for invalid or passwordless accounts to defeat username-enumeration attacks; on musl-based systems, submitting a password of 257–1,024 characters against an asterisk-marked account triggers this comparison logic in a way that grants access, a flaw that has existed since that 2016 OpenSSH change.

   Fix Details

   OpenSSH fixed the issue in version 10.6p2, released the same day the vulnerability was disclosed; any system running that build or newer is protected.

   Remediation

   Administrators unable to immediately update OpenSSH should disable password authentication and restart the SSH daemon. There is no indication that the flaw has been exploited in the wild, but Kültekin's writeup includes a simple CLI command defenders can use to check whether any no-password accounts on a system have recently accepted a password login.

4. bleepingcomputer.com ↗ · pub. 05/11/2026 14:45 · coletado 05/11 15:00

   OpenSSH "*sshole" Flaw Lets Attackers Bypass Password-Disabled Accounts on musl-based Linux Systems

   This article attributes discovery of the flaw (nicknamed "*sshole") to researcher Ozgun Kultekin, who used AI agents running about 17,600 authentication tests to find it, and traces its root cause to a 2016 OpenSSH patch for the username-enumeration bug CVE-2016-6210. It also broadens the known list of affected musl-based distributions beyond Alpine Linux to include OpenWrt, Buildroot, and Yocto, and confirms the fix landed in OpenSSH 10.6p2.

   ler a análise desta fonte ocultar

   This article attributes discovery of the flaw (nicknamed "*sshole") to researcher Ozgun Kultekin, who used AI agents running about 17,600 authentication tests to find it, and traces its root cause to a 2016 OpenSSH patch for the username-enumeration bug CVE-2016-6210. It also broadens the known list of affected musl-based distributions beyond Alpine Linux to include OpenWrt, Buildroot, and Yocto, and confirms the fix landed in OpenSSH 10.6p2.

   A newly disclosed authentication bypass dubbed *"sshole" allows attackers to log into OpenSSH accounts configured to block password authentication by simply submitting an oversized password, on Linux systems built with the musl C library such as Alpine Linux, OpenWrt, Buildroot, and Yocto. Security researcher Ozgun Kultekin discovered and disclosed the flaw, tracing its root cause to a 2016 OpenSSH patch for a username-enumeration bug (CVE-2016-6210) that made OpenSSH hash passwords even for accounts with no usable password hash, including accounts marked with an asterisk (*) to disable password logins. Because musl's crypt() function also returns * when a submitted password exceeds its 256-byte limit, an oversized password causes OpenSSH to match the returned * against the account's stored *, granting access. The flaw does not bypass accounts with valid password hashes, and only affects systems running OpenSSH with PAM authentication disabled and SSH password authentication enabled. Kultekin warns that Alpine Linux's official AWS and Azure cloud images ship a default alpine account with passwordless doas privileges, which could let an attacker who exploits this bug escalate to root.

   Technical Details

   Exploitation requires OpenSSH running on a musl-based Linux system with PAM authentication disabled (as it is by default in Alpine Linux's openssh-server package), SSH password authentication enabled, at least one account with an asterisk as its password hash, and another account with a valid password hash. Systems using glibc, including Debian, Ubuntu, and Fedora, and those using PAM authentication are not vulnerable to this attack. Kultekin found the flaw by running roughly 17,600 automated authentication tests using AI agents against different OpenSSH configurations, malformed password hashes, and oversized passwords (bleepingcomputer.com).

   Fix Details

   The vulnerability has been fixed in OpenSSH 10.6p2, consistent with the fix date already reported for this incident; Alpine Linux administrators are advised to update via apk upgrade openssh.

   Remediation

   Admins unable to patch immediately can set PasswordAuthentication no in the SSH server configuration and restart SSH. Defenders can check for exploitation by running grep "Accepted password" /var/log/messages to find successful password logins, then verifying with grep '^alpine:' /etc/shadow whether the affected account's password field contains an asterisk despite the recorded login.

5. securityonline.info ↗ · pub. 05/11/2026 11:29 · coletado 05/11 12:00 primeiro registro

   OpenSSH Password Authentication Bypass (CVE-2026-123158) Hits Alpine Linux via musl libc crypt() Flaw

   ler a análise desta fonte ocultar

   Alpine Linux issued an urgent advisory on November 5, 2026, warning that an OpenSSH authentication bypass lets attackers log in to sshd without knowing any password. Alpine describes the exploit as reliable, noting it "takes one connection, works every time, and needs no retries." The issue, now tracked as CVE-2026-123158 and rated 8.1 (High, CVSS 3.1) by researchers (ox.security), affects Linux systems where sshd is linked against musl libc and runs without PAM, with Alpine being the most prominent example. OpenSSH released version 10.6p2 the same day to address the bug, and no CVE had been assigned by Alpine at the time its advisory was published. Neither Alpine nor OpenSSH reports exploitation in the wild.

   Technical Details

   Without PAM, sshd hashes a submitted password with crypt() and compares the result to the account's stored password field. For accounts lacking a usable salt, sshd borrows the salt of another local account. musl's crypt() function returns the string "" as an error indicator when the submitted password exceeds 256 bytes (reported as 257–1024 bytes by cybersecuritynews.com); since passwordless or key-only accounts also store "" in their password field, the comparison incorrectly matches and the login succeeds. Exploitation therefore requires: the openssh-server package (or openssh-server-pam with UsePAM no), PasswordAuthentication yes (the OpenSSH default), a target account with a * password field, and at least one other local account on the machine with a $5$ or $6$ password hash. Systems using openssh-server-pam with UsePAM yes are not affected, nor are cloud-init images that disable password logins, though Alpine's official tiny-cloud images ship an alpine user with passwordless doas, meaning an attacker who gains a shell as alpine can escalate to root once any password hash exists on the system. Every Alpine release from 3.16 through 3.24 and edge is affected. OpenSSH states the root cause lies outside sshd itself but is exploitable via sshd and can be mitigated there.

   Fix Details

   OpenSSH shipped the fix in Portable OpenSSH 10.6p2, released November 5, 2026, which rejects stored password hashes too short to represent a valid hash. Alpine published corresponding patched packages across all supported branches, including openssh 10.6_p2-r0 on edge and 10.3_p1-r2 on branch 3.24, with fixes backported as far as Alpine 3.16.

   Remediation

   Administrators should run apk upgrade and restart sshd, since upgrading the package alone does not replace the running daemon. Where immediate patching is not possible, set PasswordAuthentication no and restart sshd. Defenders should also check /var/log/messages for "Accepted password" log lines tied to passwordless accounts as a sign of possible exploitation.