OpenSSH Password Authentication Bypass (CVE-2026-123158) Hits Alpine Linux via musl libc crypt() Flaw
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. The flaw, independently nicknamed "*sshole", also affects other musl-based distributions beyond Alpine, including OpenWrt, Buildroot, and Yocto (bleepingcomputer.com), and is also noted to affect musl-based systems generally, including embedded Linux deployments (theregister.com). 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. Security researcher Ozgun Kultekin is credited with discovering and disclosing the flaw, having found it by running roughly 17,600 automated authentication tests using AI agents against various OpenSSH configurations, malformed password hashes, and oversized passwords (bleepingcomputer.com).
Entenda a falha
A vulnerabilidade
*sshole (CVE-2026-123158, CVSS 3.1 8.1 High per ox.security, as cited in the story; Alpine had no CVE when it published its advisory) is an authentication bypass in OpenSSH's sshd on Linux systems that use musl libc, mainly Alpine Linux 3.16 to 3.24 and edge. BleepingComputer also lists OpenWrt, Buildroot and Yocto. A remote attacker with network access to SSH can log in to accounts that refuse passwords (an asterisk in the password field) by sending a password of 257 to 1,024 bytes. This requires sshd without PAM (the Alpine openssh-server default, or openssh-server-pam with UsePAM no), PasswordAuthentication yes, an account with an asterisk and another account with a $5$ or $6$ hash. Accounts with valid hashes are not bypassed. On Alpine tiny-cloud images the alpine user has passwordless doas, so a login can lead to root. Fixed in OpenSSH 10.6p2; Alpine ships openssh 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24, with backports to 3.16.
Como funciona
When someone logs in over SSH with a password and PAM is off, sshd hashes the supplied password with crypt() and compares the result with the account's stored password field. Since 2016, sshd also hashes passwords for accounts without a usable hash, to equalize response times. For accounts with no usable salt, it borrows the salt of another local account. On musl, crypt() returns a literal asterisk when hashing fails, including when the password exceeds 256 bytes. sshd then compares that asterisk with the asterisk stored for the disabled account, they match, and the login is accepted.
Por que é vulnerável
Several choices that were safe individually combine badly. musl's crypt() returns an asterisk, the old BSD marker for a disabled password, as an error value instead of NULL, and musl caps passwords at 256 bytes. OpenSSH's 2016 fix for username enumeration (CVE-2016-6210) added hashing for accounts without usable hashes, and sshd does not treat the returned asterisk as a failure. The OpenSSH team considers the root cause to be outside sshd, but exploitable via sshd and avoidable there. The 10.6p2 fix rejects stored password hashes too short to represent a valid hash.
Onde está
The articles name no file or commit; the flaw sits in the interaction between musl's crypt() return value and sshd's non-PAM password check, and the fix is in Portable OpenSSH 10.6p2.
Como foi descoberta
Researcher Ozgun Kultekin (Özgün Kültekin in The Register) discovered it, named it *sshole and published a writeup on 5 November 2026. According to BleepingComputer, he used AI agents that ran about 17,600 authentication tests with varied OpenSSH configurations, malformed hashes and oversized passwords. Alpine issued an urgent advisory the same day, and OpenSSH released 10.6p2 (Thursday, per The Register). Neither Alpine nor OpenSSH reports exploitation in the wild.
Explicação gerada por IA a partir da matéria e dos artigos, em 05/11/2026 19:20.
Detalhes técnicos
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. The root cause traces to a 2016 OpenSSH patch that fixed a username-enumeration vulnerability (CVE-2016-6210) by making OpenSSH hash passwords even for accounts without a usable password hash, including accounts marked with * to block password logins — a behavior that, combined with musl's error-handling quirk, enables the bypass (bleepingcomputer.com). The asterisk convention itself dates back to the BSD Unix era: BSD co-developer Bill Joy's 1980 work on BSD left a single asterisk in the /etc/passwd entry for the daemon user to disable password authentication, a convention musl's crypt() inadvertently reuses as an error return value (theregister.com). Separately, musl's SHA-512-based password hashing grows slower as password length increases, which Kültekin notes could additionally be abused for denial-of-service by flooding a server with very long passwords, a factor that led musl to cap passwords at 256 bytes in the first place (theregister.com).
Detalhes da correção
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.
Remediação
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, and can confirm suspicious logins by checking whether the affected account's /etc/shadow entry still contains * despite a logged successful password login (bleepingcomputer.com). Kültekin's writeup additionally provides a simple CLI command that can be run to check whether any no-password accounts on a sensitive machine have recently accepted a password login (theregister.com).
Linha do tempo
-
"*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/passwdor/etc/shadowto 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.
-
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'scrypt()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 defaultalpineaccount with passwordlessdoasprivileges, 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 noin the SSH server configuration and restart SSH. Defenders can check for exploitation by runninggrep "Accepted password" /var/log/messagesto find successful password logins, then verifying withgrep '^alpine:' /etc/shadowwhether the affected account's password field contains an asterisk despite the recorded login. -
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-serverpackage (oropenssh-server-pamwithUsePAM 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 usingopenssh-server-pamwithUsePAM yesare not affected, nor are cloud-init images that disable password logins, though Alpine's official tiny-cloud images ship analpineuser with passwordlessdoas, meaning an attacker who gains a shell asalpinecan 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 upgradeand restart sshd, since upgrading the package alone does not replace the running daemon. Where immediate patching is not possible, setPasswordAuthentication noand restart sshd. Defenders should also check/var/log/messagesfor "Accepted password" log lines tied to passwordless accounts as a sign of possible exploitation.