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

Linha do tempo

1. cert.cyber.gouv.fr ↗ · pub. 05/11/2026 21:00 · coletado 08/11 11:00

   Alpine Linux patches OpenSSH password authentication bypass (CVE-2026-119977) allowing passwordless login to key-only accounts

   ler a análise desta fonte ocultar

   CERT-FR published advisory CERTFR-2026-AVI-1480 on 6 November 2026 relaying the Alpine Linux security advisory of 5 November 2026 about a security policy bypass in the openssh-server package, tracked as CVE-2026-119977. CERT-FR lists as affected Alpine 3.21.x before 3.21.10, 3.22.x before 3.22.8, 3.23.x before 3.23.8 and 3.24.x before 3.24.4, and notes that branch 3.21 reached end of support on 1 November 2026 but still received a fix, as did the obsolete 3.16 to 3.20 branches. The Alpine advisory describes an attacker able to reach the SSH port logging in without knowing any password, in a single connection and with no retries (alpinelinux.org). Exploitation requires the name of an account whose password field is * (key-only accounts, root, users from a directory service through musl-nscd, or the alpine user of tiny-cloud images) and at least one other local account carrying a $5$ or $6$ hash; the attacker then sends a password of 257 to 1024 bytes (alpinelinux.org). Systems running openssh-server-pam with UsePAM yes, or with PasswordAuthentication no, and containers that do not run sshd, are not affected (alpinelinux.org).

   Technical Details

   When sshd is built without PAM, it verifies a password by hashing the attempt with crypt() and comparing it to the stored field; for an account whose stored field is too short to hold a salt, sshd borrows the salt of another account. musl's crypt() returns the string * as an error indicator when the key exceeds 256 bytes, which is exactly the stored field of every passwordless account, so the comparison matches and the login succeeds (alpinelinux.org). Official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas, so an attacker obtaining that shell can escalate to root once any $6$ hash exists on the machine (alpinelinux.org). The flaw was reported by Özgün Kültekin of Wakefield, with the fix produced by Damien Miller and Darren Tucker of the OpenSSH project (alpinelinux.org).

   Fix Details

   The issue is corrected upstream in OpenSSH 10.6p2, and Alpine stable branches carry a backported patch for the same problem (alpinelinux.org). Fixed openssh package versions are 10.6_p2-r0 on edge, 10.3_p1-r2 (3.24), 10.2_p1-r1 (3.23), 10.0_p1-r11 (3.22), 9.9_p2-r1 (3.21), 9.7_p1-r6 (3.20), 9.6_p1-r3 (3.19), 9.3_p2-r4 (3.18), 9.1_p1-r7 (3.17) and 9.0_p1-r6 (3.16), shipped with the 3.21.10, 3.22.8, 3.23.8 and 3.24.4 point releases (alpinelinux.org).

   Remediation

   Run apk upgrade for openssh and then restart the daemon with rc-service sshd restart, since upgrading the package does not replace the running sshd (alpinelinux.org). Where upgrading is not yet possible, set PasswordAuthentication no in the sshd configuration (or in a /etc/ssh/sshd_config.d drop-in, honoured from 3.19 onward) and restart sshd. Cloud instances built from tiny-cloud images earlier than 3.21.10/3.22.8/3.23.8/3.24.4 must be updated or have password authentication disabled. For hunting, review /var/log/messages for sshd lines reading Accepted password for an account with no password, and audit doas usage, recently created users and authorized keys (alpinelinux.org).

2. cert.cyber.gouv.fr ↗ · pub. 04/11/2026 21:00 · coletado 08/11 11:00

   CERT-FR updates OpenSSH 'sshole' alert: CVE-2026-123158 assigned, Alpine advisory published, sshd restart mandatory

   The CERT-FR alert bulletin CERTFR-2026-ALE-015 was updated on November 6, 2026: it now carries the identifier CVE-2026-123158, references the Alpine Linux security bulletin of November 5, adds a second CERT-FR advisory (CERTFR-2026-AVI-1480), and insists that any patch or configuration change be followed by a restart of the sshd service. It also publishes the researcher's detection one-liner for spotting accepted password logins on accounts whose /etc/shadow field is `*`.

   ler a análise desta fonte ocultar

   The CERT-FR alert bulletin CERTFR-2026-ALE-015 was updated on November 6, 2026: it now carries the identifier CVE-2026-123158, references the Alpine Linux security bulletin of November 5, adds a second CERT-FR advisory (CERTFR-2026-AVI-1480), and insists that any patch or configuration change be followed by a restart of the sshd service. It also publishes the researcher's detection one-liner for spotting accepted password logins on accounts whose /etc/shadow field is *.

   CERT-FR updated its alert bulletin CERTFR-2026-ALE-015 on November 6, 2026 on the OpenSSH password authentication bypass affecting versions before 10.6p2. The update assigns the identifier CVE-2026-123158 to the flaw and notes that Alpine Linux has published its own security bulletin dated November 5, 2026. CERT-FR stresses that any patch installation or configuration change must be followed by a restart of the sshd service, otherwise the vulnerable daemon keeps running. The initial publication described the condition: on Linux systems using musl libc, built without PAM support or with PAM disabled, an attacker can authenticate by supplying two passwords, the second strictly longer than 256 characters and shorter than 1,024. CERT-FR calls the flaw trivial to exploit when the conditions are met, and the bulletin does not mention exploitation in the wild or give a CVSS score.

   Technical Details

   • Affected profile: OpenSSH before 10.6p2 on Linux with musl libc, compiled without PAM or with PAM disabled (cert.cyber.gouv.fr).
   • Exploitation: two password prompts, the second with a length strictly greater than 256 and less than 1,024 characters, bypasses authentication.
   • Hunting: the researcher who found the flaw recommends checking the legitimacy of logins for every system account whose /etc/shadow password field is * (password disabled), for example with awk -F : '$2 == "*" {print $1}' /etc/shadow | xargs -r -I{} grep "Accepted password for {}" /var/log/messages run as root.
   • References listed: the Alpine bulletin 2026-11-05-openssh-password-authentication-bypass, the OpenSSH 10.6p2 release notes, advisories CERTFR-2026-AVI-1468 and CERTFR-2026-AVI-1480, and the sshhole.com site.

   Remediation

   • Apply the vendor fix (OpenSSH 10.6p2 or the distribution package) and restart sshd afterwards.
   • Where patching is impossible, disable password authentication or, failing that, disable the SSH service.
   • Review Accepted password log entries for passwordless accounts.
3. zdnet.com ↗ · pub. 06/11/2026 21:00 · coletado 06/11 22:00

   OpenSSH auth bypass CVE-2026-123158 on musl: Alpine ships fixes, Wind River reviewing impact

   ZDNET adds that Wind River is reviewing whether Wind River Linux is affected and extends the list of potentially exposed musl-based systems to Adélie Linux, Void Linux, Sabotage Linux and an Android variant alongside OpenWrt and Yocto. It also notes that Alpine 3.21 reached end of support on November 1, days before the point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 shipped the fix, and gives the concrete upgrade sequence `apk upgrade -U -a` followed by `rc-service sshd restart`.

   ler a análise desta fonte ocultar

   ZDNET adds that Wind River is reviewing whether Wind River Linux is affected and extends the list of potentially exposed musl-based systems to Adélie Linux, Void Linux, Sabotage Linux and an Android variant alongside OpenWrt and Yocto. It also notes that Alpine 3.21 reached end of support on November 1, days before the point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 shipped the fix, and gives the concrete upgrade sequence apk upgrade -U -a followed by rc-service sshd restart.

   Alpine Linux and OpenSSH have patched CVE-2026-123158, an authentication bypass affecting sshd built without PAM on musl libc systems. An attacker who knows the name of a passwordless or key-only account can log in by sending a password of 257 to 1,024 bytes, because musl's crypt() returns * on error — the same value stored in the password field of accounts with no password. The flaw, introduced as a side effect in 2016 according to the *sshole group that reported it, requires PasswordAuthentication to be enabled (the OpenSSH default) and at least one other account carrying a $5$ or $6$ hash. Alpine says every release it checked is affected (3.16 through 3.24 and edge) and singled out its tiny-cloud images 3.18.11 to 3.24.3, which ship an alpine user with a * password field and passwordless doas. Other musl-based systems — Adélie Linux, Void Linux, Sabotage Linux, OpenWrt, an Android variant and the Yocto Project — are potentially exposed, and Wind River told ZDNET it is reviewing the impact on Wind River Linux. glibc distributions such as Debian, Ubuntu and Fedora are not affected because glibc's crypt() returns NULL on error, which sshd already rejects.

   Technical Details

   • Without PAM, sshd hashes the submitted password with the C library's crypt() and compares the result with the stored password field.
   • musl's crypt() refuses keys longer than 256 bytes and returns the string *, which matches the * stored for passwordless accounts, so authentication succeeds. sshd's own 1,024-byte password limit sets the upper bound.
   • Exposure requires: the openssh-server package built without PAM (or openssh-server-pam with UsePAM no); PasswordAuthentication yes; an account with * as its password field; and another account with a $5$ or $6$ hash. One user with a password is enough to make every passwordless account accessible.
   • Root is generally protected by the default PermitRootLogin prohibit-password despite shipping as root:* since about Alpine 3.16, but any reachable account that can escalate through doas still provides a path to root.
   • Not affected: containers not running sshd, systems with password authentication disabled, openssh-server-pam with UsePAM yes, accounts locked with !, and cloud images configured by cloud-init (which writes PasswordAuthentication no).

   Remediation

   • Alpine released 3.21.10, 3.22.8, 3.23.8 and 3.24.4 on Thursday with the OpenSSH fix, plus fixed packages for every release back to 3.16; Alpine 3.21 reached end of support on November 1. OpenSSH 10.6p2 avoids the problem in sshd.
   • Run apk upgrade -U -a and then rc-service sshd restart: upgrading the package does not replace the running daemon.
   • Where patching is impossible, set PasswordAuthentication no and restart sshd after confirming key-based login works.
   • Hunt in /var/log/messages for "Accepted password for" lines naming accounts with no password, review doas use and recently created users, files and authorized keys; treat the machine as compromised if a login cannot be ruled out.
4. 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.
5. cert.cyber.gouv.fr ↗ · pub. 04/11/2026 21:00 · coletado 06/11 12:00

   CERT-FR relays OpenSSH 10.6p2 fix for sshd password authentication bypass (CVE-2026-123158)

   ler a análise desta fonte ocultar

   The CERT-FR bulletin CERTFR-2026-AVI-1468 relays the OpenSSH 10.6p2 release of 5 November 2026. It covers CVE-2026-123158, a security policy bypass that CERT-FR attributes to OpenSSH versions before 10.6p2. The OpenSSH release notes describe a password authentication bypass in sshd(8) and call the fix a "critical security workaround" (openssh.org). The OpenSSH notes do not cite the CVE, which comes only from CERT-FR, so linking CVE-2026-123158 to the password bypass is an inference. The OpenSSH notes mention specific Linux builds (musl libc, PAM disabled). The CERT-FR page also carries an unrelated banner about a notification campaign targeting Apple phones on 29 October 2026.

   Technical Details

   According to the OpenSSH release notes, the root cause lies outside sshd, but sshd can be exploited through it, so the workaround is in sshd (openssh.org). The notes say it affects some Linux systems when OpenSSH is built and run with PAM support disabled. The introduction names musl libc together with PAM being disabled as the affected profile, so the notes read during research describe one combined configuration: Linux, musl libc, PAM disabled (openssh.org). The CVE identifier comes from the CERT-FR bulletin. The OpenSSH release notes read during research do not cite it, and they do not give a full list of affected versions. They list the fix as a change since 10.6p1 (openssh.org). The flaw was reported by Özgün Kültekin of Wakefield (openssh.org). The sources read do not mention exploitation in the wild or give a CVSS score.

   Remediation

   CERT-FR directs readers to the OpenSSH 10.6p2 bulletin for the fix and lists versions before 10.6p2 as affected. Upgrade OpenSSH to 10.6p2 or later. According to the OpenSSH notes, the practical risk concerns builds with PAM disabled on Linux systems using musl libc (openssh.org). Administrators should check whether their builds match that profile.

6. 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.
7. 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).
8. 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.
9. 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.
10. 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.
11. 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).
12. 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.
13. 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.