OpenSSH 'sshole' sshd auth bypass (CVE-2026-123158) on musl/Alpine Linux, fixed in 10.6p2, now exploited in the wild

Linha do tempo

1. thehackernews.com ↗ · pub. 06/11/2026 12:21 · coletado 06/11 15:00

   Attackers exploit OpenSSH 'SSHole' auth bypass (CVE-2026-123158) within hours, root confirmed on Alpine honeypot

   The article confirms and details Previdian's in-the-wild exploitation finding: eight attempts from 89.116.89[.]18 (Japan), confirmed root on an Alpine honeypot less than nine hours after CVE publication, and adds Safe Security's enterprise impact assessment that a successful SSHole login inherits the account's privileges and may expose deployment credentials, application secrets and connected infrastructure, enabling lateral movement or service disruption.

   ler a análise desta fonte ocultar

   The article confirms and details Previdian's in-the-wild exploitation finding: eight attempts from 89.116.89[.]18 (Japan), confirmed root on an Alpine honeypot less than nine hours after CVE publication, and adds Safe Security's enterprise impact assessment that a successful SSHole login inherits the account's privileges and may expose deployment credentials, application secrets and connected infrastructure, enabling lateral movement or service disruption.

   Previdian reports in-the-wild exploitation of CVE-2026-123158 (CVSS 8.1), the OpenSSH authentication bypass codenamed SSHole (*sshole), with the first attempt seen less than nine hours after CVE publication and confirmed root access on an Alpine Linux honeypot. The flaw lets an unauthenticated attacker log in to accounts whose password field is * by supplying an oversized password of 257 to 1,024 bytes, with no stolen credentials or keys. It affects Linux systems running OpenSSH on musl libc with PAM disabled, including Alpine's default openssh-server configuration; glibc distributions, non-Linux systems, PAM-based password checking and Dropbear are not affected. Telemetry shows eight attempts from a single IP geolocated to Japan, which ran id, uname and hostname in non-interactive sessions. The bug was found by researcher Ozgun Kultekin and fixed in OpenSSH 10.6p2. Impact is bounded by the privileges of the bypassed account, but Safe Security notes it can expose deployment credentials, application secrets and connected infrastructure, enabling lateral movement.

   Technical Details

   • The root cause dates to a July 2016 OpenSSH change made to fix the username-enumeration bug CVE-2016-6210: without PAM, sshd hashes the submitted password and compares it to the stored field.
   • musl's crypt() returns * on failure for $5$/$6$ passwords longer than 256 bytes; sshd then compares that * with the * stored for password-disabled accounts and accepts the login. The 1,024-byte upper bound is sshd's own password limit.
   • Exploitation requires at least one account with * as its password hash; accounts holding a valid hash cannot be bypassed.
   • Observed activity: source IP 89.116.89[.]18 (Japan), oversized passwords followed by reconnaissance commands.

   Remediation

   • Install OpenSSH 10.6p2 or the distribution's patched package, then restart sshd (the upgrade does not replace the running daemon).
   • Hunt in /var/log/messages for Accepted password for entries on accounts that should not accept password logins (alpine, root, key-only users).
   • Review doas use and recently created users, files and authorized keys on exposed machines; treat any host where a bypass login cannot be ruled out as compromised.
   • Monitor or block 89.116.89[.]18.
2. helpnetsecurity.com ↗ · pub. 06/11/2026 09:49 · coletado 06/11 10:01

   OpenSSH 'sshole' musl auth bypass (CVE-2026-123158) exploited in the wild within hours; root access on Alpine honeypot

   First report of exploitation in the wild: Previdian saw attempts less than nine hours after CVE publication and confirmed root access on an Alpine honeypot. All eight attempts came from 89.116.89[.]18 (Japan). This contradicts earlier reports that said there was no sign of exploitation. The article also notes unverified GitHub PoCs that may contain malware and that CISA KEV does not list the flaw.

   ler a análise desta fonte ocultar

   First report of exploitation in the wild: Previdian saw attempts less than nine hours after CVE publication and confirmed root access on an Alpine honeypot. All eight attempts came from 89.116.89[.]18 (Japan). This contradicts earlier reports that said there was no sign of exploitation. The article also notes unverified GitHub PoCs that may contain malware and that CISA KEV does not list the flaw.

   Threat intelligence firm Previdian reports active exploitation of CVE-2026-123158 ("sshole"), an OpenSSH authentication bypass on musl-based Linux systems such as Alpine Linux. It was found by Özgün Kültekin and fixed in OpenSSH 10.6p2 on November 5. Previdian's first observed attempt came less than nine hours after CVE publication, and it confirmed successful root access on a honeypot running real Alpine Linux and OpenSSH. The company counted eight attempts, all from 89.116.89[.]18 (Japan) and all caught by a single sensor. CISA has not added the flaw to KEV, while Previdian lists it as exploited. Unverified proof-of-concept exploits on GitHub may contain malware.

   Technical Details

   • The source IP used oversized passwords (over 256 characters) to bypass authentication. It then ran the reconnaissance commands id, uname and hostname in non-interactive SSH sessions (helpnetsecurity.com, quoting Previdian's Ryan Dewhurst).
   • Root cause: since 2016 sshd borrows another account's salt and hashes the password even when an account has no usable hash (CVE-2016-6210 fix). musl's crypt() returns "" for SHA-256/SHA-512 passwords longer than 256 bytes. That output matches the "" stored for passwordless accounts, so the login succeeds.
   • Prerequisites: musl without PAM, password logins enabled (the default), an account with only "*" in /etc/shadow, and another local account with a password hash. Key-only users and musl-nscd directory users fit the target description. Root is protected by the default PermitRootLogin unless an admin changed it. The Alpine tiny-cloud images 3.18.11 to 3.24.3 have an alpine user with passwordless doas, which gives indirect root (SOCRadar, via helpnetsecurity.com).
   • Not affected: glibc systems (Debian, Ubuntu, Fedora), PAM setups, Dropbear and OpenBSD.
   • Dewhurst attributes the speed of exploitation partly to AI and to the trivial nature of the bug.

   Remediation

   • Update to OpenSSH 10.6p2. Alpine patched packages for branches 3.16 to edge the same day. Restart sshd, because the update leaves the running daemon untouched.
   • If you cannot update, set PasswordAuthentication=no or disable SSH, as Damien Miller urged.
   • Search /var/log/messages for "Accepted password for" entries naming passwordless accounts (alpine, root, key-only users). Review doas use, recently created users and authorized_keys. Treat any host where a login cannot be ruled out as compromised.
   • Block or monitor 89.116.89[.]18.
3. securityweek.com ↗ · pub. 06/11/2026 09:07 · coletado 06/11 10:00

   OpenSSH 10.6p2 fixes 'SSHole' sshd authentication bypass (CVE-2026-123158) on musl libc systems such as Alpine Linux

   SecurityWeek confirms CVE-2026-123158 and gives a CVSS score of 8.1 (high), which conflicts with the earlier "critical" rating. It adds Detectify's and watchTowr's expectation that scanning for the flaw will start within hours or days, and Miller's statement that the flaw is not in sshd itself. It repeats that no exploitation has been seen.

   ler a análise desta fonte ocultar

   SecurityWeek confirms CVE-2026-123158 and gives a CVSS score of 8.1 (high), which conflicts with the earlier "critical" rating. It adds Detectify's and watchTowr's expectation that scanning for the flaw will start within hours or days, and Miller's statement that the flaw is not in sshd itself. It repeats that no exploitation has been seen.

   OpenSSH released emergency version 10.6p2 for a high-severity authentication bypass dubbed SSHole and tracked as CVE-2026-123158 (CVSS 8.1). It affects sshd on Linux distributions that use musl libc with PAM disabled. Attackers can log in to accounts that have no password, such as root, by sending any password of 257 to 1,024 characters. Wakefield researcher Özgün Kültekin found the flaw. Alpine Linux urged users to patch and restart sshd, or to disable password logins. Alpine has seen no exploitation so far, but Detectify and watchTowr expect scanning within hours or days because the attack is a single connection (securityweek.com).

   Technical Details

   • The bug is a "misinterpretation of whether a string is intended to be a password hash". Per OpenSSH developer Damien Miller, the flaw is not in sshd itself but can be exploited via sshd.
   • Affected distributions include Alpine, OpenWrt, Buildroot and Yocto, where accounts such as root can accept passwords.
   • Alpine's conditions: OpenSSH runs without PAM, password authentication is enabled, an account has * as its password field (root, key-only users, the alpine user in tiny-cloud images, or musl-nscd directory users), and at least one local account has a $5$ or $6$ hash. Alpine has used * for root since 3.16.
   • Affected Alpine releases are 3.21 to 3.24, edge and the unsupported 3.16 to 3.20.
   • Alpine says one connection is enough and the attack works every time. Detectify's Fredrik Almroth notes that Shodan lists about 22 million hosts with SSH on port 22 (securityweek.com).

   Remediation

   • Apply the OpenSSH patches (10.6p2 or the distribution's fixed package) and restart sshd, because the running daemon is not replaced by the package upgrade alone. If you cannot patch, disable password authentication and restart sshd (securityweek.com).
   • Miller said the release was made within a day of learning of the bug. He cited recent cases of AI agents rediscovering bugs within hours and called long embargoes dangerous (securityweek.com).
4. gbhackers.com ↗ · pub. 06/11/2026 03:06 · coletado 06/11 04:00

   OpenSSH 'sshole' flaw (CVE-2026-123158) lets 257+ character passwords log into password-disabled accounts on musl Linux

   gbhackers.com reports that the flaw is tracked as CVE-2026-123158. Earlier sources said no CVE had been assigned. It also adds that the bypass takes two prompts (a wrong password, then about 300 characters), and that Alpine fixed packages exist for 3.16 through 3.24 and edge.

   ler a análise desta fonte ocultar

   gbhackers.com reports that the flaw is tracked as CVE-2026-123158. Earlier sources said no CVE had been assigned. It also adds that the bypass takes two prompts (a wrong password, then about 300 characters), and that Alpine fixed packages exist for 3.16 through 3.24 and edge.

   A decade-old authentication bypass in OpenSSH sshd on musl libc systems without PAM, dubbed *"sshole" and tracked as CVE-2026-123158 (gbhackers.com), lets an attacker log in to accounts that store * in the password field. Any password of 257 to 1,024 characters works. The flaw affects Alpine Linux, and OpenWrt, Buildroot and Yocto builds that use OpenSSH on musl. OpenSSH 10.6p2 shipped on November 5, 2026 with a workaround. Researcher Özgün Kültekin of Wakefield found it with AI agents that ran about 17,600 unusual logins. The article reports no exploitation in the wild.

   Technical Details

   • musl's crypt() has returned * on failure since 2012, and it fails for SHA-512 passwords longer than 256 bytes. Since 2016, sshd hashes the attempt with another account's salt to prevent username enumeration. With a long password, crypt() returns *, which matches the stored *, and access is granted.
   • The researcher's repository shows two prompts are enough: any wrong password first, then about 300 "A" characters.
   • Conditions that must all hold, per Check Point and the researcher's checks as cited by the article: sshd on musl without PAM (Alpine's default openssh-server build); PasswordAuthentication enabled (the default); an account whose password field is exactly *; and another active local account with a real $5$ or $6$ hash.
   • Not affected: glibc systems (Debian, Ubuntu, Fedora), PAM-based authentication, Dropbear and OpenBSD.
   • Alpine's official AWS and Azure cloud images are a concern because the default alpine user has passwordless doas, which gives root.
   • OpenSSH says it considers the root cause to be outside sshd, but it added a workaround. It also says releases will be more frequent because AI tools surface bugs quickly.

   Remediation

   • Run apk upgrade openssh and then restart sshd, because the package update does not restart the running daemon. Alpine published fixed packages for releases 3.16 through 3.24 and edge.
   • If you cannot patch, set PasswordAuthentication no, for example in /etc/ssh/sshd_config.d/00-no-passwords.conf, and restart sshd.
   • Search authentication logs for "Accepted password" entries on accounts with no password. Treat any such host as compromised: rotate keys and credentials and look for persistence.
   • Run the researcher's check.sh on musl hosts, because CVE-based scanners may miss the flaw.
5. thehackernews.com ↗ · pub. 05/11/2026 13:42 · coletado 05/11 20:00

   OpenSSH 10.6p2 fixes sshd auth bypass for passwordless accounts on musl-based Alpine Linux via 257–1,024-byte passwords

   This article adds Alpine's four exposure conditions, the fixed Alpine point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4), the affected tiny-cloud range (3.18.11 to 3.24.3), the musl history from 2012, the exact form of the 10.6p2 workaround (refusing a stored field shorter than four characters), and Miller's statement on embargoes and AI-found bugs.

   ler a análise desta fonte ocultar

   This article adds Alpine's four exposure conditions, the fixed Alpine point releases (3.21.10, 3.22.8, 3.23.8, 3.24.4), the affected tiny-cloud range (3.18.11 to 3.24.3), the musl history from 2012, the exact form of the 10.6p2 workaround (refusing a stored field shorter than four characters), and Miller's statement on embargoes and AI-found bugs.

   OpenSSH released 10.6p2 on November 5, 2026 to fix an authentication bypass in sshd on systems that use musl libc without PAM. Alpine Linux is the main affected platform. The flaw was reported by Özgün Kültekin of Wakefield. An attacker with network access and the name of a passwordless account (* in the password field) can log in by sending a password of 257 to 1,024 bytes. This works only if another local account has a $5$ or $6$ hash and PasswordAuthentication is enabled. OpenSSH rates the flaw critical. No attacks have been reported and no CVE had been assigned. Alpine has published fixed packages for every release back to 3.16.

   Technical Details

   • Without PAM, sshd hashes the attempt with crypt() and compares it to the stored field. A * field is too short to hold a salt, so sshd borrows the salt of another account. This salt borrowing comes from a July 15, 2016 OpenSSH change for CVE-2016-6210 (username enumeration).
   • For $5$ and $6$ hashes, musl's crypt() refuses passwords longer than 256 bytes and returns *. That matches the stored *, so the login is accepted. The upper limit is sshd's own 1,024-byte password limit. musl made failed crypt() return an unmatchable hash instead of NULL on August 9, 2012. It added the 256-byte limit on August 29, 2012, to prevent denial of service.
   • Alpine's advisory lists four conditions, all of which must hold:
     • openssh-server (built without PAM), or openssh-server-pam with UsePAM no.
     • PasswordAuthentication yes (the default).
     • An account with * as its password field.
     • At least one other local account with a $5$ or $6$ hash.
   • The attack succeeds on every try with a single connection. One account with a password exposes every passwordless account.
   • Passwordless accounts on Alpine include key-only users, musl-nscd directory users, root (root:* since about 3.16) and the alpine user in tiny-cloud images. Root is protected by the default PermitRootLogin prohibit-password. It is still reachable through any exposed account that can use doas.
   • The tiny-cloud images from 3.18.11 through 3.24.3 give alpine passwordless doas. They are safe at first boot but exposed once any $6$ hash exists, for example after an admin sets a console password.
   • Not affected: glibc Linux, non-Linux systems, PAM-based password checking, containers without sshd, PasswordAuthentication no, cloud-init images, accounts locked with !, and machines with no $ hash. Kültekin names OpenWrt, Buildroot and Yocto as other musl systems to check. OpenWrt's default Dropbear is not affected, only an installed OpenSSH server.
   • The 10.6p2 change makes sshd refuse a match when the stored field is shorter than four characters. OpenSSH calls it a workaround and says the root cause lies outside sshd.

   Remediation

   • On Alpine, run apk upgrade -U -a, then rc-service sshd restart. Upgrading the package does not restart the running sshd.
   • Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix. Branches 3.16 to 3.21 are end of support but also got fixed packages. Tiny-cloud instances from older images still need the update.
   • If you cannot update, set PasswordAuthentication no (including inside Match blocks). Confirm key login works first, run sshd -t, restart sshd, and verify with sshd -T | grep -i passwordauthentication. Alpine's default configuration reads drop-ins in /etc/ssh/sshd_config.d from 3.19 onward.
   • Check /var/log/messages for Accepted password lines for passwordless accounts. On exposed machines, review doas use, new users, files and authorized_keys. If a login cannot be ruled out, treat the machine as compromised.
   • Damien Miller of OpenSSH said to set PasswordAuthentication=no or disable SSH on affected systems immediately. He said the project now sees long embargoes as dangerous because AI agents rediscover bugs within hours.
6. blog.checkpoint.com ↗ · pub. 05/11/2026 17:56 · coletado 05/11 19:00

   OpenSSH 10.6p2 fixes SSH password bypass on musl-based Linux without PAM, including Alpine; Check Point adds exposure guidance

   Check Point's testing adds that the second account holding the $5$/$6$ hash must be active, not just hold a hash. It also adds that the bug is partly visible remotely (banner version, password authentication offered), and that Alpine's fixed packages keep older version strings, so patched hosts can look vulnerable. It notes that CVE-based scanners may miss the flaw, that root is safe under the default prohibit-password, and that the OpenSSH team shipped the fix one day after learning of the bug.

   ler a análise desta fonte ocultar

   Check Point's testing adds that the second account holding the $5$/$6$ hash must be active, not just hold a hash. It also adds that the bug is partly visible remotely (banner version, password authentication offered), and that Alpine's fixed packages keep older version strings, so patched hosts can look vulnerable. It notes that CVE-based scanners may miss the flaw, that root is safe under the default prohibit-password, and that the OpenSSH team shipped the fix one day after learning of the bug.

   OpenSSH 10.6p2, released on November 5, 2026, fixes a critical password authentication bypass in sshd on musl-based Linux with PAM disabled. Alpine Linux is the common example. Check Point says anyone who can reach the SSH port can log in as a passwordless account without a password. No CVE had been assigned as of November 5, 2026. The post does not mention exploitation in the wild.

   Technical Details

   • Without PAM, sshd hashes the password attempt with crypt() and compares it to the stored field. When an account has no salt, sshd borrows the salt of another account.
   • musl's crypt() returns * as an error for input over 256 bytes. Accounts with no password also store *. A password of 257 to 1,024 bytes therefore "matches" and the login succeeds. Per the Alpine advisory, this takes one connection and works every time.
   • All of these conditions must hold:
     • sshd runs without PAM on musl, such as Alpine's openssh-server, or openssh-server-pam with UsePAM no.
     • PasswordAuthentication is yes, the OpenSSH default.
     • An account has * in its password field. Examples are key-only users, directory users through musl-nscd, and the alpine user in official tiny-cloud images.
     • At least one other active local account has a real $5$ or $6$ hash.
   • Check Point's testing adds that a stored hash alone is not enough. The account holding the hash must be active.
   • Root is safe under the default PermitRootLogin prohibit-password. Any reachable account with doas or sudo rights can still become root.
   • According to OpenSSH developer Damien Miller, glibc Linux, non-Linux systems and Linux with PAM are not affected.
   • Two conditions are visible remotely: the OpenSSH version in the banner, and whether password authentication is offered. The musl, PAM, account-state and hash conditions need a check on the host.
   • Version strings can mislead. Alpine's fixed packages keep older numbers, such as 10.3_p1-r2 on Alpine 3.24, so a patched host can look vulnerable. CVE-based scanners may also miss affected systems because there is no CVE.

   Remediation

   • Alpine ships patched packages for 3.16 through 3.24 and edge. Upgrade, then restart sshd, because the package upgrade does not restart the running daemon.
   • If you cannot patch yet, set PasswordAuthentication no.
   • Search logs for "Accepted password for" an account that has no password. If a login cannot be ruled out, treat the machine as compromised.
   • Prioritize internet-facing SSH servers that accept passwords, and Alpine containers, using asset inventory rather than CVE lists.
   • Check Point says the OpenSSH team released the fix one day after learning of the bug. Its stated reasoning is that AI agents rediscover bugs quickly, so long embargoes mainly help attackers. Check Point advises planning for an OpenSSH update every one to two months.
7. theregister.com ↗ · pub. 05/11/2026 15:29 · coletado 05/11 16:00

   OpenSSH 10.6p2 fixes 'sshole' sshd authentication bypass via over-long passwords on musl libc systems such as Alpine Linux

   The Register adds the exploitable password length window (257 to 1,024 characters), the affected account types (key-only deployment users and LDAP users), the note that direct root login still depends on the OpenSSH configuration, the history of the `*` marker and of musl's 256-byte cap, and the statement that 10.6p2 was released Thursday. It also repeats that there is no sign of exploitation.

   ler a análise desta fonte ocultar

   The Register adds the exploitable password length window (257 to 1,024 characters), the affected account types (key-only deployment users and LDAP users), the note that direct root login still depends on the OpenSSH configuration, the history of the * marker and of musl's 256-byte cap, and the statement that 10.6p2 was released Thursday. It also repeats that there is no sign of exploitation.

   Researcher Özgün Kültekin disclosed "*sshole", an authentication bypass in OpenSSH sshd on Linux systems that use musl libc instead of glibc. An attacker who supplies a password of 257 to 1,024 characters can log in to accounts that are not meant to accept passwords, such as key-only deployment users and LDAP users. Accounts with * in the password field are the ones affected. Direct root login stays subject to the OpenSSH configuration. The flaw dates to 2016 and is fixed in OpenSSH 10.6p2. The article says there is no indication of exploitation (theregister.com).

   Technical Details

   • Conditions: musl libc, sshd running without PAM, password authentication enabled, at least one account with * in its password field, and at least one other account with a valid password hash (theregister.com).
   • musl's crypt() returns the single character * on certain failures instead of NULL. musl also caps passwords at 256 bytes, so a longer password makes crypt() return *, which matches the * stored for disabled accounts (theregister.com).
   • A 2016 OpenSSH change performs dummy password hashing to stop timing-based account enumeration. This is what exposes the musl behavior (theregister.com).
   • Musl is common in embedded Linux and is the standard C library of Alpine Linux. Alpine's official AWS and Azure cloud images may be vulnerable depending on configuration (theregister.com).
   • The article traces the use of * for disabled accounts back to 1980 BSD Unix (theregister.com).

   Remediation

   • Update to OpenSSH 10.6p2 or later. The article says it was released Thursday (theregister.com).
   • If you cannot update, disable password authentication and restart sshd (theregister.com).
   • The writeup includes a CLI command to check whether any no-password accounts recently accepted a password (theregister.com).
8. bleepingcomputer.com ↗ · pub. 05/11/2026 14:45 · coletado 05/11 15:00

   'sshole' OpenSSH flaw on musl-based Linux lets oversized passwords log into password-disabled accounts

   BleepingComputer names the researcher (Ozgun Kultekin) and the "sshole" label, and says the flaw dates to a 2016 OpenSSH change for CVE-2016-6210. It extends the affected systems to OpenWrt, Buildroot and Yocto, says the bug was found with AI agents, and says Alpine's AWS and Azure cloud images carry an affected `alpine` account with passwordless doas. It also gives the exploitation-check commands.

   ler a análise desta fonte ocultar

   BleepingComputer names the researcher (Ozgun Kultekin) and the "sshole" label, and says the flaw dates to a 2016 OpenSSH change for CVE-2016-6210. It extends the affected systems to OpenWrt, Buildroot and Yocto, says the bug was found with AI agents, and says Alpine's AWS and Azure cloud images carry an affected alpine account with passwordless doas. It also gives the exploitation-check commands.

   Researcher Ozgun Kultekin disclosed "sshole", a flaw in how OpenSSH sshd works with the musl C library. An attacker can log into accounts whose password is disabled with * in /etc/shadow by submitting an oversized password. It affects musl-based distributions such as Alpine Linux, OpenWrt, Buildroot and Yocto. Kultekin says it has existed since 2016. It is fixed in OpenSSH 10.6p2. The article does not mention a CVE or exploitation in the wild. glibc systems (Debian, Ubuntu, Fedora) and systems using PAM are not affected.

   Technical Details

   • A 2016 OpenSSH patch for the username-enumeration bug CVE-2016-6210 made sshd hash the password even when an account has no usable hash, so that response times do not reveal valid usernames.
   • musl's crypt() returns * when hashing fails, including when the password exceeds its 256-byte limit. sshd then compares that * with the stored * and accepts the login.
   • Accounts with valid password hashes cannot be bypassed this way.
   • Prerequisites, per the researcher: OpenSSH on a musl system; PAM disabled (the default in Alpine's openssh-server package); SSH password authentication enabled; at least one account with * as its hash; and another account with a valid hash.
   • Alpine's official AWS and Azure cloud images have a default alpine account with passwordless doas, which could lead to root access.
   • Kultekin says he found the bug with AI agents that ran about 17,600 authentication tests with varied configurations, malformed hashes and oversized passwords.

   Remediation

   • Update to OpenSSH 10.6p2. On Alpine, run apk upgrade openssh.
   • If you cannot patch yet, set PasswordAuthentication no and restart SSH.
   • To check for exploitation, run grep "Accepted password" /var/log/messages on Alpine. If it shows password logins for the alpine account, run grep '^alpine:' /etc/shadow. A * in the password field combined with a successful password login suggests exploitation.
9. securityonline.info ↗ · pub. 05/11/2026 11:29 · coletado 05/11 12:00 primeiro registro

   OpenSSH 10.6p2 fixes musl crypt() sshd password bypass on Alpine Linux for accounts with no password set

   ler a análise desta fonte ocultar

   Alpine Linux issued an urgent advisory on November 5, 2026 about an OpenSSH authentication bypass. It lets an attacker log in to sshd as any passwordless account without knowing a password. The flaw affects Linux systems that use musl libc with PAM disabled, and every Alpine release from 3.16 to edge. OpenSSH 10.6p2 blocks it. No CVE had been assigned at the time of writing. Neither Alpine nor OpenSSH reports exploitation in the wild.

   Technical Details

   • Without PAM, sshd hashes the submitted password with crypt() and compares the result to the stored password field. For accounts with no usable salt, sshd borrows the salt of another account.
   • musl's crypt() returns "" as an error when the key is longer than 256 bytes. Passwordless, key-only accounts store "" in the password field, so the "hash" matches and the login succeeds.
   • Alpine says it takes one connection, works every time, and needs no retries.
   • Prerequisites: the openssh-server package, or openssh-server-pam with UsePAM no, plus PasswordAuthentication yes (the OpenSSH default). The machine needs a passwordless account and at least one $5$ or $6$ password hash. One user with a password is enough to make every account without one reachable.
   • The official tiny-cloud images ship an alpine user with passwordless doas. Once any password hash exists, an attacker gets a shell as alpine and can become root.
   • Not affected: openssh-server-pam with UsePAM yes, and cloud-init images, which disable password logins.
   • The OpenSSH team says it considers the root cause to be outside sshd, but the bug is exploitable via sshd and can be avoided there.

   Remediation

   • Run apk upgrade, then restart sshd. Upgrading the package alone does not replace the running daemon.
   • Fixed builds include openssh 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24. Alpine also published fixes back to 3.16.
   • If you cannot update, set PasswordAuthentication no and restart sshd.
   • Check /var/log/messages for "Accepted password" lines on passwordless accounts.