OpenSSH 10.6p2 fix: who is exposed to the password-bypass flaw, and who isn't

OpenSSH 10.6p2, released Nov. 5, works around a flaw that lets a very long password log an attacker into accounts that have no usable password. It affects Linux servers using the musl C library without PAM, not Debian, Ubuntu, Fedora or macOS. Evidence on consumer routers is thin, and the likeliest router exposure is a manually installed OpenSSH server.

A flaw fixed in OpenSSH 10.6p2 can let an attacker log in to a Linux server by sending an extremely long password. It works only where a specific set of conditions line up: the server runs the musl C library, checks passwords without PAM (the Pluggable Authentication Modules framework), and has an account with no usable password. Damien Miller of the OpenSSH project said non-Linux systems, Linux systems built on glibc and systems that check passwords through PAM are not affected.

The bug, tracked as CVE-2026-123158 and nicknamed "sshole," matters for two reasons. Attackers reportedly tried to exploit it within hours of disclosure, and the people most at risk may not realize they run an exposed service, such as an Alpine-based cloud image or container with an SSH server inside. The popular framing, that OpenSSH lets anyone in without a password, overstates the problem for most readers.

What the bug actually does

According to analysis by the security firm Ethiack, the trouble starts in a C library function called crypt(), which checks a typed password against a stored one. When musl's version receives a password longer than 256 bytes, it signals an error by returning a single asterisk as a string. glibc, the other common C library, returns NULL in the same situation, and sshd already rejects that result.

On Alpine Linux, Ethiack reports, a single asterisk is also what the password file stores for an account that has no password. sshd then compares the asterisk from the error against the asterisk in the file, finds them identical and accepts the login. The Hacker News reports that the attacker needs network access to the server, an account name and a password between 257 and 1,024 bytes long. Cyber Security News gave a reproduction example: a password of 300 repeated "A" characters could get past authentication for an affected account.

BleepingComputer reports that the weakness dates to 2016 and traces back to a patch for a username-enumeration bug, CVE-2016-6210, which changed how OpenSSH handles password-verification errors on musl. The flaw was reported to OpenSSH by Özgün Kültekin of Wakefield, according to Ox Security. Flawfence reports the report came on Nov. 4, and OpenSSH shipped 10.6p2 the next day.

Why "password-free" is a loose description

Nothing here removes the password from a normal account. BleepingComputer states that the flaw does not allow bypassing passwords on accounts that hold valid password hashes. The target is an account in a no-password state, such as a key-only user that was created without a password. The attacker sends an oversized password, and the library's error is mistaken for a match.

Accounts locked with an exclamation mark rather than an asterisk are not affected, according to Ox Security. That detail shows how specific the failure is: it depends on one stored value happening to equal one error string.

The conditions that must all hold

SecurityWeek relays Alpine's description of an exposed deployment. All of the following must be true:

• OpenSSH runs without PAM handling the password check.
• Password authentication is enabled.
• An account exists whose password field is an asterisk. Examples include root, a key-only user created with adduser without a password, the alpine user in official tiny-cloud images, or a directory-service user resolved through musl-nscd.
• At least one local account has a password hash beginning with $5$ or $6$.

The Hacker News adds that Alpine's openssh-server package is built without PAM and that password logins are on by default. Cycode reports that root is shielded by the default PermitRootLogin setting of prohibit-password, though a cloud image where a default user has passwordless doas rights can allow escalation to root after login, according to Ox Security. Cycode says the passwordless alpine user exists on official cloud images 3.18.11 through 3.24.3.

Who is affected, and who is not

The clearest statement of scope comes from the OpenSSH project. Miller said non-Linux systems, glibc-based Linux and PAM-based password checking are outside the problem. Ox Security lists Debian, Ubuntu and Fedora as unaffected, along with any system where PasswordAuthentication is off. Flawfence reports that Red Hat says none of its products are affected and that macOS and OpenBSD are also clear, though that is a single-source claim not checked against Red Hat.

Within Alpine, the picture splits by package. Cyber Security News reports that systems using the openssh-server-pam package with UsePAM set to yes are unaffected, while Cycode says the same package with UsePAM set to no is affected. The practical test is therefore whether PAM is actually being used for password checks. Containers that do not run sshd are not affected, per Ox Security and Privacy Affairs.

BleepingComputer names the musl-based platforms that could be exposed under certain authentication setups: Alpine Linux, OpenWrt, Buildroot and Yocto. That list describes where the musl library is common, not a confirmed count of vulnerable products. Nobody has published a tally of exposed hosts, so how many real systems are reachable remains unknown.

Whose bug is it?

The OpenSSH release notes, as reproduced by undeadly.org, say the project considers the root cause to lie outside OpenSSH but that it could deliver a mitigation quickly. According to The Hacker News, 10.6p2 makes sshd refuse a match when the stored password field is shorter than four characters. That closes the asterisk-equals-asterisk path without touching the C library. The brief did not establish whether musl itself will change the error value crypt() returns.

Routers: what the evidence supports

Most home routers are probably not affected, but that is an inference from the firmware many of them use rather than a tested result. Konfirmity, Ox Security and Cyber Kendra each say OpenWrt's default SSH server is Dropbear, a different program that is not affected. Konfirmity attributes this to the musl maintainer's advisory. OpenWrt therefore matters mainly where someone has installed the OpenSSH server by hand.

Sources do not fully agree. Horizon3.ai lists "OpenWrt, and other embedded devices" as affected, and its page labels the bug a remote code execution flaw. That is looser and stronger than the other reports, which tie the risk to OpenSSH being installed, and the label is not supported elsewhere in the brief. An explainer cited in the research calls the idea that every OpenWrt home router is compromised a myth.

The security firm IONIX reports a lab finding for the case where OpenSSH is installed on OpenWrt. Its openssh-server package is built against musl, without PAM, with password authentication on. IONIX says that once root has a password, system accounts named daemon, network and nobody, which use /bin/false as a shell, could be abused as network tunnels into the local network. That finding comes from one vendor and was not corroborated.

Buildroot and Yocto are build systems for embedded devices, and the researcher's list, relayed by BleepingComputer, names them as possible exposures depending on how an image is configured. As of Nov. 6, Cyber Kendra reported, OpenWrt, Buildroot and Yocto had not published a fix status. No statement from a consumer router maker such as TP-Link, Netgear, Asus or Ubiquiti, or from an internet-provider gateway, appears in the research.

Since router-specific checks were not documented in the sources, the reasoning is more useful than a recipe. Three questions decide exposure: whether SSH is switched on at all, whether the device runs Dropbear or OpenSSH, and whether the firmware is built on musl. A router with SSH off, or one running Dropbear, falls outside the reported conditions. A device with OpenSSH on a musl build, password logins enabled and no PAM deserves a closer look, and the manufacturer's security notice is the right place to confirm.

How to check a Linux system

The commands below were reported by secondary sources, not by OpenSSH or Alpine directly, so administrators should compare them against the vendor advisories. They suit someone who already manages a Linux server or container image.

1. Identify the C library with `ldd --version 2>&1 | head -1`. A result mentioning GLIBC or GNU libc means sshole does not apply, while musl means further checks are needed (a note.com write-up).
2. Read the effective SSH settings, as root, with `sshd -T | grep -i -E 'passwordauthentication|usepam'`. Cycode says a system is not exposed if password logins are off or PAM is on.
3. On Alpine, list the installed package with `apk info -v | grep '^openssh'` and compare it with the fixed versions in the table below (Konfirmity; a DEV Community guide).
4. Search logs for "Accepted password" entries. BleepingComputer says a successful password login to an account whose password field is an asterisk could indicate exploitation.

Checking from the outside

Check Point notes that two conditions are visible from outside before any login: the OpenSSH version in the SSH banner, and whether the server accepts password authentication. The banner alone misleads, though. Alpine backports fixes into the version each branch already ships, so a patched machine may display an older number, and one source (TechNWZ) cautions that a lower version number does not by itself mean a system is vulnerable.

How to install the fix

Alpine did not move its stable branches to 10.6p2. Per a Medium post, and consistent with the advisory's version table, it patched the OpenSSH version each branch already carried and raised the package release number. A patched Alpine machine therefore will not report 10.6p2, and the table below is the reference.

The table comes from a copy of the Alpine advisory on daily.dev, and the 3.16, 3.24 and edge values match Ox Security and MLQ. The Hacker News reports that fixed packages exist for every release back to 3.16. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package. Branches 3.16 through 3.21 are past end of support but were patched anyway.

The advisory's commands, as reproduced by daily.dev, are `apk upgrade -U -a` to pull the update, followed by `rc-service sshd restart`. The restart matters because upgrading the package does not restart a daemon that is already running, so the old code can keep serving logins.

If patching has to wait

Privacy Affairs and a DEV Community audit guide describe a stopgap: set PasswordAuthentication to no and restart sshd. Two cautions come with it. Match blocks in the configuration can switch password logins back on, so they need review, and key-based login should be confirmed in a second session before the first one is closed, to avoid locking the administrator out.

Self-built OpenSSH on musl

For OpenSSH compiled by hand on musl without PAM, the answer is to move to 10.6p2, which also carries ordinary bug fixes from the 10.6 stable branch, according to undeadly.org. Rescana, citing heise, reports that on release day many other distributions and download mirrors still offered 10.6p1, so the version actually installed is worth confirming. The previous release, 10.6, came out on Oct. 6, 2026, per a Wikipedia snippet.

How strong is the evidence of attacks?

Help Net Security reported on Nov. 6 that the threat-intelligence firm Previdian saw its first exploitation attempt less than nine hours after the CVE was published. The firm also said it confirmed successful root access on a honeypot running real Alpine Linux and OpenSSH. Other outlets, including The Hacker News, repeat the claim, but it traces to that one source.

Counter-signals exist. HawkEye reports that other vendor write-ups published on Nov. 6 described no confirmed in-the-wild exploitation, and the flaw was not in CISA's Known Exploited Vulnerabilities catalog when those pieces were written. Cyber Kendra notes CISA marks the exploitation status as "poc," meaning proof-of-concept code is public. Neither OpenSSH nor Alpine reported attacks. A fair reading is exploitation attempts reported by one firm, public proof-of-concept code, and no independent confirmation yet.

Previdian's advice, relayed by Help Net Security, is that a machine where a malicious login cannot be ruled out should be treated as compromised. That is a security vendor's recommendation, not an official standard. It does explain why the log search above checks for password logins to accounts that should not accept them.

Why the patch came so fast

In a post on Hachyderm, Miller said the release went out as fast as possible because the project learned of the problem only the day before. He said the project has seen multiple cases of AI agents rediscovering bugs rapidly, sometimes within hours, and now considers long embargo periods dangerous. Privacy Affairs, quoting the release notes, reports the project has received a large number of security bug reports, many from AI models or AI-assisted work, and will release more often for now.

Severity labels differ by source. The OpenSSH release notes describe the release as carrying a critical security workaround. SecurityWeek reports a CVSS 3.1 score of 8.1, which falls in the High band, assigned by MITRE. Both figures are reasonable, since they come from different assessors.

What it means, and what to watch

The sshole flaw is a reminder that a security failure can sit between two components, each behaving as designed. musl returns an error string, Alpine stores the same string for a no-password account, and sshd treats the match as a pass. The fix is small, but finding every place the combination exists is harder, especially in containers and embedded builds where nobody remembers installing an SSH server.

For most readers, the reported scope suggests no action beyond staying informed. For administrators of Alpine-based systems, the work is concrete: upgrade, restart sshd, review logs. Developments to watch include vendor statements from router makers, fix status for OpenWrt, Buildroot and Yocto, any CISA listing, and independent confirmation of the reported attacks.

Frequently asked questions

Is my home router affected by the OpenSSH flaw?

Probably not, though no router-maker statements were found. Several sources say OpenWrt's default SSH server is Dropbear, which is not affected. A router is a concern mainly if it runs the OpenSSH server on a musl-based build with password logins on and no PAM.

Are Windows, macOS, Ubuntu or Debian affected?

Not by this flaw, according to the sources. OpenSSH's Damien Miller said non-Linux systems, glibc-based Linux and PAM-based password checks are unaffected. Ox Security lists Debian, Ubuntu and Fedora as clear, and Flawfence reports macOS and OpenBSD are not affected.

How do I install the OpenSSH 10.6p2 fix on Alpine Linux?

Alpine's advisory, as reproduced by daily.dev, says to run apk upgrade -U -a and then restart the daemon with rc-service sshd restart. Alpine patched each branch's existing version, so the installed package will not say 10.6p2. Compare it with the fixed-version table in the advisory.

What can be done if patching isn't possible yet?

Privacy Affairs and a DEV Community guide suggest setting PasswordAuthentication to no and restarting sshd. Match blocks can turn password logins back on, so they need checking. Key-based login should be confirmed in a second session first.

Has the flaw been exploited in real attacks?

Previdian reported a first attempt less than nine hours after CVE publication and root access on a honeypot. That is a single source, other write-ups reported no confirmed exploitation, and the flaw was not in CISA's KEV catalog when last checked on Nov. 5 to 6.

Sources

1. OpenSSH 10.6p2 released , undeadly.org (OpenBSD Journal) (2026-11-05)
2. Damien Miller: OpenSSH 10.6p2 has been released , Hachyderm.io (2026-11-05)
3. Alpine Linux Security advisory: OpenSSH-server password authentication bypass , daily.dev (copy of Alpine advisory) (2026-11-05)
4. OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux , The Hacker News
5. OpenSSH Rushes Patches for 'SSHole' Authentication Bypass , SecurityWeek
6. OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158) , Help Net Security (2026-11-06)
7. OpenSSH flaw lets attackers log into password-disabled Linux accounts , BleepingComputer
8. A Critical SSH Password Bypass Hits musl-Based Linux , Check Point
9. OpenSSH Password Authentication Bypass on Alpine Linux (*sshole) , Ox Security
10. CVE-2026-123158 (sshole): OpenSSH Password Bypass on Alpine Linux , Ethiack
11. sshole (CVE-2026-123158): OpenSSH password bypass on Alpine Linux , Cycode
12. SSHhole (CVE-2026-123158) and how IONIX is helping you respond , IONIX (2026-11-05)
13. sshhole CVE-2026-123158: Alpine SSH Bypass Fix , Konfirmity (2026-11-05)
14. CVE-2026-123158: OpenSSH musl Bypass (*sshole) , Horizon3.ai
15. CVE-2026-123158: OpenSSH sshhole Bypass Hits Alpine Linux , Cyber Kendra (2026-11-06)
16. sshole: The OpenSSH Bug That Logs You In to Accounts With No Password , HawkEye
17. OpenSSH 10.6p2 Fixes Password Bypass on Alpine Linux , Privacy Affairs
18. OpenSSH 10.6p2 Fixes Critical Password Bypass on Alpine and musl Linux: What to Do Now , Rescana
19. Critical OpenSSH Flaw Could Let Attackers Bypass Password Authentication on Alpine Linux Servers , Cyber Security News
20. CVE-2026-123158 (sshole): OpenSSH on Alpine, fixed versions, Flawfence , Flawfence
21. OpenSSH 10.6p2 Fixes an Alpine Password Bypass. Your Patched Alpine Box Will Not Say 10.6p2. , Medium (C. Shringi)
22. Alpine's sshd can be accessed with a single long password—sshole (CVE-2026-123158) conditions and what to do today , note.com (zephel01)
23. OpenSSH Password Bypass on Alpine: How to Audit and Fix the Alpine OpenSSH Password Bypass , DEV Community
24. OpenSSH SSHole Flaw Exploited Within Hours on Alpine , TechNWZ

This article was drafted with the help of AI and reviewed by Jaroha editors before publication.