OpenSSH 10.6p2 Password Bypass on Alpine Linux Explained: CVE-2026-123158 and the Fix

Image: Alpine Linux — Alpine Linux logo (Wikimedia Commons). Alpine is the Linux distribution most affected by the flaw.

UPDATE — 6 November 2026, 19:45 IST: Exploitation in the wild is now confirmed. Threat-intelligence firm Previdian says its sensors picked up attacks against CVE-2026-123158 less than nine hours after the CVE was published, and confirmed successful root access on a honeypot running real Alpine Linux and OpenSSH — the attacker (source IP 89.116.89.18) used oversized passwords and ran reconnaissance commands (id, uname, hostname). Separately, watchTowr has also detected active exploitation attempts, driven mainly by automated botnets and cryptocurrency miners. The flaw is still not in CISA's Known Exploited Vulnerabilities catalogue. If you run an affected Alpine/OpenSSH setup and have not patched yet, update to OpenSSH 10.6p2 now — or switch off password logins immediately. Sources: Help Net Security; SecurityOnline.

TL;DR — OpenSSH 10.6p2 password bypass Alpine Linux explained in one line: a flaw tracked as CVE-2026-123158 lets anyone who can reach your SSH port log in to a password-less account with a password longer than 256 bytes — no password to guess, no exploit code needed. Alpine Linux is the main target, the fix is OpenSSH 10.6p2, and if you cannot patch yet, switching off password logins stops it immediately.

📌 KEY HIGHLIGHTS

• Released 5 November 2026: OpenSSH shipped 10.6p2 with what it calls a critical security workaround for Linux systems using the musl C library with PAM disabled.
• The flaw is CVE-2026-123158 (CVSS 8.1, High): a password between 257 and 1,024 bytes is accepted for accounts that were never supposed to take a password at all.
• Alpine Linux is the main target: its standard openssh-server package is built without PAM, so its default setup is exposed. OpenWrt, Buildroot and Yocto builds can be affected too.
• Worst case is root: Alpine's official cloud images ship a default alpine user with no password and passwordless doas — logging in as that user is effectively root.
• Exploitation in the wild is now confirmed (see the update above) — patch now, do not wait.

OpenSSH 10.6p2 password bypass Alpine Linux explained: what happened?

On 5 November 2026, the OpenSSH project released Portable OpenSSH 10.6p2. The release notes are blunt: the update contains "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled". The bug was reported by researcher Özgün Kültekin of Wakefield, who published the full story — including a six-panel comic of how the bug came to be — at sshhole.com. The flaw has already picked up a nickname, "sshhole", and an identifier, CVE-2026-123158, rated 8.1 (High) on the CVSS scale.

What makes this one unusual is that it is not a buffer overflow, a crash or a memory bug. It is a logic bug that only appears when two long-standing behaviours meet — one in OpenSSH, one in the musl C library — and it has been sitting there for about a decade, since portable OpenSSH 7.3 in 2016. Kültekin says he found it by throwing roughly 17,600 unusual logins at sshd builds, with help from AI agent swarms, according to his write-up. OpenSSH's own release notes note the same trend: the project has received a large number of security reports recently, many of them findings from AI models or made with AI assistance, and says it will release more frequently to get fixes out faster.

How the bypass works — two old behaviours, one bad combination

To understand the bug, you need two pieces of history. First, the star. In Unix, an account that should never accept a password gets a single * in its password field instead of a hash. A * is not a hash, so no password can ever match it. Key-only users, service accounts and directory-service users commonly have this.

Second, the salt. In 2016, OpenSSH fixed a timing flaw (CVE-2016-6210) that let attackers work out which usernames existed by measuring how long sshd took to answer. The fix: when there is no real hash to check — for a nonexistent user, or an account with a * — sshd borrows some other account's salt and hashes the password anyway, just to take the same amount of time. Still a no, just a slower no.

Illustrative image: unofficial SSH logo (Wikimedia Commons / Jessie Kirk, CC BY-SA). The official OpenSSH logo is not freely licensed, so this is a stand-in, not the project's mark.

Now add musl, the C library Alpine Linux is built on. For SHA-256 and SHA-512 hashes, musl refuses passwords longer than 256 bytes — a denial-of-service guard, because hashing gets slower as the password gets longer. When it refuses, its crypt() function returns a single character to signal the failure. That character is *. And * is exactly what is stored in the password field of the account being attacked. So the comparison succeeds, and the login is granted.

Put together, the attack is almost embarrassingly simple: the attacker sends one wrong password, then a password longer than 256 bytes (up to sshd's 1,024-byte limit) in the same connection, and walks into an account that has no password. TuxCare reproduced it on Alpine Linux 3.18: the second try in one connection logs in. There is nothing to guess and nothing to brute-force — the attacker only needs the name of a target account.

Who is affected — and who is not

The bug only fires when four conditions are all true on the same server, so most systems are safe. But Alpine's defaults tick every box.

Condition	What it means for you
sshd runs on musl libc	Alpine Linux always uses musl; also some OpenWrt, Buildroot and Yocto builds
sshd does not use PAM	Alpine's default openssh-server package is built without PAM
Password logins are on	PasswordAuthentication yes is the OpenSSH default
A * account exists — plus another account with a $5$ or $6$ hash	Key-only users, LDAP users, root on Alpine 3.16+; the other account supplies the borrowed salt

The worst case is Alpine's official cloud images. Their default alpine user has a * password field and passwordless doas, so logging in as that user is effectively root — and Alpine says its tiny-cloud images from 3.18.11 through 3.24.3 ship this user. One honest nuance: root itself is also * on Alpine 3.16 and later, but the default PermitRootLogin prohibit-password setting blocks password login for root directly, so the cloud user is the real danger, not root.

If you run Debian, Ubuntu, Fedora, RHEL or any other glibc-based distribution, you are not affected. The same goes for any setup that routes password checks through PAM, for Dropbear, for OpenBSD, and for any server with password logins already switched off. Alpine is also the base image for a huge share of Docker containers — but only containers that actually run sshd are exposed; a container without an SSH server has nothing to attack.

Why it matters for Indian readers

Alpine's tiny footprint makes it the default base image for countless Docker containers, and Indian startups, developers and cloud teams run a lot of those — in CI pipelines, on jump hosts, in small services and on appliances. If any of your Alpine boxes or containers run sshd with the default settings, they are in scope, and the check takes a minute. This is also the second major security story of the week aimed squarely at Indian infrastructure: CERT-In's Crafty Falcon advisory, issued on 4 November, warned that AI-driven attacks are already hitting Indian banks and fintech firms — see our CERT-In's Crafty Falcon advisory. The lesson from both is the same: the defaults you never changed are the ones attackers study first.

There is also a timing warning worth passing on. As of 5 November, neither OpenSSH nor Alpine had reported exploitation in the wild — but exploitation has now been confirmed; see the update at the top of this post. The flaw is not in CISA's Known Exploited Vulnerabilities catalogue. But public reproduction labs already exist, so working exploits should be assumed to be available. Zyxel's GS1900 zero-day, which compromised 996 switches before it was patched — see our Zyxel's GS1900 zero-day — is a reminder of how fast that window closes.

How to fix it now

The fix is short, but the restart matters — upgrading the package does not necessarily restart a running sshd, so an unpatched server can keep answering logins after the upgrade.

1. Patch Alpine. Run apk upgrade openssh (or apk upgrade -U -a), then restart the service with rc-service sshd restart. Alpine has shipped fixed packages for every release back to 3.16, including 3.18, which reached end of life in May 2025 and was fixed as an exception. Container images that run sshd need to be rebuilt with the fixed package, not just restarted.

2. Patch from-source builds. If you built OpenSSH yourself on musl without PAM, move to 10.6p2. The release is a workaround, not a root-cause fix: 10.6p2 makes sshd refuse to compare a password when the stored field is shorter than four characters. OpenSSH says the root cause sits in musl; the musl maintainer says it is erroneous use by the caller. Either way, the workaround closes the path.

3. If you cannot patch yet, switch off password logins. First confirm key-based login works and keep an existing session open. Then add PasswordAuthentication no — on Alpine 3.19 and later, a drop-in file at /etc/ssh/sshd_config.d/00-no-passwords.conf works — validate with sshd -t and restart sshd. OpenSSH developer Damien Miller's advice to operators of affected systems was blunt: "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."

4. Check whether you were already hit. Any successful password login to an account whose /etc/shadow field is * means the box was breached — such an account should never have accepted a password. The researcher published a checker for this at github.com/oz9un/sshole. If you find one, treat the machine as compromised and rebuild it; changing the password is not enough.

To check whether a box is in scope at all, run as root: ldd $(command -v sshd) | grep -i musl for the library, sshd -T | grep -i usepam for PAM, and sshd -T | grep -i passwordauthentication for password logins — then look for * fields in /etc/shadow.

Should you care?

✅ Verdict: patch today if you run Alpine with sshd — otherwise, check and move on. This is a genuinely critical bug with a trivial fix, and the only people at real risk are those running OpenSSH on musl without PAM, which in practice means Alpine. If that is you, the upgrade plus restart takes minutes and there is no reason to wait for an exploit to appear first. If you run Ubuntu, Debian or any PAM-based setup, you are not affected — but the story is still a useful reminder to switch off password logins wherever keys already work.

Price and availability

There is nothing to buy: OpenSSH is free and open source, and the fix ships as a free package update on every supported Alpine release. The only cost is the few minutes the upgrade and restart take — and the rebuild for any container images that run sshd. For context, Cisco's exploited Brotli flaw now affects 19 of its products — see our Cisco's exploited Brotli flaw. Patching promptly is the recurring theme of the week.

FAQs

Is my server affected by the OpenSSH password bypass?

Only if all four conditions hold: sshd runs on musl libc (Alpine Linux, mainly), sshd does not use PAM, password logins are switched on, and there is an account with * in its password field plus another local account with a SHA-256 or SHA-512 password hash. Debian, Ubuntu, RHEL, any PAM setup, Dropbear and OpenBSD are not affected.

How do I fix the OpenSSH Alpine vulnerability?

Run apk upgrade openssh and then restart sshd with rc-service sshd restart — the restart is essential, because the upgrade alone may not restart the running server. Rebuild any container images that run sshd. If you cannot patch yet, set PasswordAuthentication no, validate with sshd -t, and restart sshd.

Is Ubuntu affected by CVE-2026-123158?

No. Ubuntu uses glibc, not musl, and its sshd routes password checks through PAM, so the bug's conditions cannot occur. The same applies to Debian, Fedora, RHEL and their derivatives. Only musl-based systems running sshd without PAM — Alpine above all — are in scope.

Has the OpenSSH flaw been exploited?

Yes — exploitation in the wild has now been confirmed (see the update at the top of this post): Previdian confirmed a successful root-access attack on an Alpine honeypot, and watchTowr has detected active exploitation attempts. The flaw is still not in CISA's Known Exploited Vulnerabilities catalogue — patch now; do not wait.

TAKEAWAY: A ten-year-old quirk in how OpenSSH and musl handle a single * turned a password-less account into an open door — and the fix is one upgrade and one restart. Check your Alpine boxes today.

Follow World Tech on TechByCountry for tomorrow's update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

Sources

• OpenSSH 10.6p2 release notes — primary source: release date, critical workaround, reporter credit
• sshhole.com — researcher write-up by Özgün Kültekin — primary source: full mechanism, history, affected conditions
• TuxCare — The SSH Authentication Bypass That Lived Between OpenSSH and musl — reproduction on Alpine 3.18, Alpine package versions
• Security Boulevard / IONIX — SSHhole (CVE-2026-123158) — CVSS 8.1, affected/not-affected scope, self-check steps
• Rescana — OpenSSH 10.6p2 Fixes Critical Password Bypass on Alpine and musl Linux — Alpine advisory details, NVD status, CISA KEV check, Damien Miller quote