OpenSSH 10.6p2 Fixes the Alpine Login Bug: Check Your Servers Today

OpenSSH 10.6p2 fixes a nasty login bug, nicknamed “sshole,” that lets an attacker walk into some Alpine Linux servers with one very long password. If you run Alpine or OpenWrt with password logins on, update sshd and restart it today. The risk is narrow, but the fix takes about two minutes.

Here are the facts you need before reading further.

• Fixed in OpenSSH 10.6p2, released November 5, 2026.
• Tracked as CVE-2026-123158, rated 8.1 (High) by MITRE.
• Hits Linux systems that use musl libc and run sshd without PAM, such as default Alpine.
• Ubuntu, Debian, Red Hat and other glibc systems are not affected.
• No attacks in the wild reported as of November 6, per SOCRadar.

How the sshole bug lets a long password through

Normally, an account with no password has just a “*” in its password field. That means nobody can log in with a password. The bug breaks that promise.

Without PAM, sshd checks your password by hashing it and comparing the result with the stored value. For a passwordless account, sshd borrows the salt from another account’s real hash. That quirk dates back to a 2016 fix.

Here is the catch. On musl, the hashing function refuses passwords longer than 256 bytes and returns “*” instead of an error. That output matches the stored “*”, so sshd says yes. According to SOCRadar, one connection and a valid account name are enough.

The 2016 change was meant to stop attackers from telling real usernames from fake ones by timing the response. It worked on glibc. On musl, the same shortcut meets a stricter hashing function, and the two disagree in a dangerous way.

That is why the story reaches beyond Alpine. BleepingComputer’s report, OpenSSH flaw lets attackers log into password-disabled Linux accounts, names OpenWrt as another musl-based system to check. Many routers and tiny containers run it without anyone thinking about the C library underneath.

Is your server affected? Four conditions, all required

The bug only works when every one of these is true. Check them against your own setup.

• sshd is built without PAM, or UsePAM is set to no.
• PasswordAuthentication is yes, which is the OpenSSH default.
• At least one account has “*” as its password field.
• At least one other local account has a real $5$ or $6$ hash.

Miss any one and the trick fails. Still, many small images, containers and routers meet all four by default.

Alpine “tiny-cloud” images from 3.18.11 through 3.24.3 raise the stakes. The default alpine user can run doas without a password, so a successful login can quickly become root, as long as another account has a real password.

Which Alpine package fixes the OpenSSH 10.6p2 bug?

Alpine backported the fix to older branches instead of forcing 10.6p2 everywhere. Find your release below and make sure you have at least this package version.

Older branches back to 3.16 also got patches. Images built from the 3.21.10, 3.22.8, 3.23.8 or 3.24.4 point releases, or later, already include the fix. For OpenWrt and other musl systems, check your vendor’s advisory.

How to patch and lock down sshd in five minutes

Start with the update, then close the door that the bug used. Do both if you can.

On Alpine, run apk upgrade -U -a, then rc-service sshd restart. Installing the package alone does not restart the running sshd, so skip the restart and you are still exposed.

Next, turn off password logins and use keys. Set PasswordAuthentication no, ideally in a drop-in file under /etc/ssh/sshd_config.d on Alpine 3.19 and later. Check every line, including Match blocks.

Run sshd -t before restarting, then sshd -T | grep -i passwordauthentication to confirm. Keep one session open while you test a key login, so a typo can’t lock you out.

Signs someone already got in

No one has reported attacks in the wild, but public test labs exist on GitHub. A quick log check is cheap.

Search /var/log/messages for “Accepted password for” lines naming accounts that should have no password. Then review doas use, new users and every authorized_keys file. Alpine’s advice is blunt: treat a machine as compromised if you can’t rule a login out.

This is the same discipline we covered in our Linux kernel TCP flaw patch guide and in what to patch after AI found 948 root bugs: patch fast, restart the service, then check logs.

Frequently Asked Questions

Does the OpenSSH 10.6p2 bug affect Ubuntu or Debian?

No. Those systems use glibc and normally authenticate through PAM, so the bug doesn’t apply. Non-Linux systems and Dropbear are also listed as unaffected.

Do I have to upgrade to OpenSSH 10.6p2 on Alpine?

Not necessarily. Alpine shipped backported fixes for stable branches, such as 10.3_p1-r2 on 3.24. Any package at or above the version in the table is fine.

Is the sshole bug being exploited right now?

As of November 6, 2026, no in-the-wild attacks were reported. CISA rates exploitation as proof of concept, and public lab setups exist, so don’t wait.

What is the fastest workaround if I can’t update?

Set PasswordAuthentication no and restart sshd. Without password logins, the long-password trick has nothing to attack.

Our take

If you run Alpine in containers or cloud images, treat this as a same-day job, not a weekend one. Password logins on internet-facing servers were never a great idea, and this bug is a good excuse to switch to keys for good. For everyone on Ubuntu, Debian or Red Hat, you can relax, but forward this to the friend who runs a home router on OpenWrt.