OpenSSH sshole flaw: is your server affected?

Is your server affected by the OpenSSH sshole flaw?

The OpenSSH sshole flaw, CVE-2026-123158, is a password authentication bypass in sshd. It affects Linux systems that use musl libc and have PAM (pluggable authentication modules) disabled. In practice that means Alpine Linux, plus containers and embedded devices built the same way. A standard Ubuntu, Debian or Red Hat Enterprise Linux (RHEL) server builds sshd against glibc with PAM. That puts it outside the conditions the CVE describes. The fix is OpenSSH 10.6p2, released on 5 November 2026, or your distribution's patched package.

This guide gives the verdict for each platform. Then it gives four checks you can run on your own machines, and the fix.

Who reported it, and what OpenSSH says

Özgün Kültekin of Wakefield reported the bug. It was disclosed on the oss-security mailing list on 5 November 2026, the same day OpenSSH 10.6p2 shipped. The OpenSSH release notes describe a bypass that "affects some Linux systems when built and run with PAM support disabled". They add: "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there."

The root cause is in how musl's crypt() function reports a failure. sshd is the program that turned that failure into a successful login. The upstream fix is commit 4353fdc4, titled "avoid password authn bypass". It makes sshd refuse to compare against a stored password field shorter than four characters. The researcher's own write-up is at sshhole.com. The official CVE text is on the Debian security tracker.

What a system needs for the bug to apply

Every one of these must be true. If even one is false, the CVE as published does not apply to that sshd.

• sshd runs on musl libc, not glibc.
• sshd does not use PAM. Alpine's plain openssh-server package is built without PAM, and any build can also be set to UsePAM no.
• Password authentication is on. The sshd_config manual gives PasswordAuthentication a default of yes.
• At least one account has a password field of exactly * in /etc/shadow. The CVE text only says "for some configurations of accounts". The researcher gives key-only users, LDAP users and root on Alpine as typical examples. The researcher also says a second account with a real password hash must exist.

The researcher also lists what is not affected: glibc systems, PAM setups, Dropbear and OpenBSD. Accounts locked with ! are reported as safe.

Ubuntu, Debian and RHEL: outside the CVE's scope

These distributions link sshd against glibc and build it with PAM. That is the opposite of both conditions in the CVE text. The trackers say different things, though, so here is what each one showed on 7 November 2026.

• Red Hat states: "Red Hat products are not affected by this vulnerability." The reason it gives is that RHEL and all Red Hat product builds link OpenSSH against glibc and use PAM by default.
• Debian marks bookworm (1:9.2p1-2+deb12u10), trixie (1:10.0p1-7+deb13u4) and forky (1:10.6p1-1) as vulnerable. Only sid (1:10.6p2-1) is marked fixed. The tracker gives no note that explains the status. It looks like tracking by version number, because Debian's build rules use --with-pam and Debian ships glibc. Do not read it as "Debian is exploitable". Do not read it as "Debian is not affected" either. Watch the page for an update.
• Ubuntu lists openssh as "Needs evaluation" for 26.04, 24.04, 22.04 and 20.04 LTS, at priority Medium. Ubuntu has not published an assessment yet.
• Rocky Linux, AlmaLinux and Fedora had no advisory for this CVE that we could find. They rebuild from the same sources as RHEL, so the same glibc and PAM reasoning should apply. That is our inference, not a statement from those projects. Check your distribution's errata page.

You do not have to rely on any tracker. The four checks below show the libc and the PAM setting of your own sshd in under a minute. If you want a repeatable process for every CVE, not only this one, see how to check your server for known CVEs.

Where a VPS owner can still have the bug

An Alpine VPS

Alpine ships two sshd packages. openssh-server is described as "OpenSSH server" and does not depend on libpam. openssh-server-pam is described as "OpenSSH server with pam support" and depends on libpam.so.0. Both link musl. Having the -pam package installed does not prove that PAM is in use. The effective UsePAM value decides that, so check it.

Alpine patched every listed branch on 5 November 2026. The Alpine security tracker gives these fixed versions:

• edge: 10.6_p2-r0
• 3.24: 10.3_p1-r2
• 3.23: 10.2_p1-r1
• 3.22: 10.0_p1-r11
• 3.21: 9.9_p2-r1
• 3.20: 9.7_p1-r6
• 3.19: 9.6_p1-r3

Only edge carries OpenSSH 10.6p2. The stable branches got a backport, so they keep their older OpenSSH version number. Compare the package revision (-rN), not the OpenSSH version. An Alpine 3.22 box on 10.0_p1-r11 is fixed, even though it reports OpenSSH 10.0. The tracker page stops at 3.19, but Alpine's advisory says the team "published fixed packages for each release all the way back to 3.16". It lists 3.18 as 9.3_p2-r4, 3.17 as 9.1_p1-r7 and 3.16 as 9.0_p1-r6. The advisory lists no fixed package for branches older than 3.16. A box on one of those needs a branch upgrade.

Alpine-based containers that run sshd

Many container images are built on Alpine, and some of them run sshd. The popular linuxserver/openssh-server image is built from baseimage-alpine:3.24. It installs openssh-server-pam, not the plain package. Its init script turns password login on only when you set PASSWORD_ACCESS=true. Otherwise it sets PasswordAuthentication no. We could not confirm the image's UsePAM value from its published files, so check it in your running container.

On 7 November 2026, Docker Hub showed the latest tag as 10.3_p1-r2-ls242. That revision matches Alpine 3.24's fixed package. A container is only fixed if it was created from that image or a newer one. An old container keeps its old package until you pull the new image and recreate the container.

Routers and embedded boards

OpenWrt's default package list includes dropbear, so a stock OpenWrt image uses Dropbear as its SSH server. The researcher says Dropbear is not affected. OpenWrt's package feed also carries OpenSSH, with separate PAM and non-PAM builds. A device where someone installed OpenSSH therefore needs the checks below. On Buildroot and Yocto boards, the answer depends on how the image was built. The rule is the same everywhere: an affected device runs OpenSSH's sshd on musl without PAM.

Check your own server in four commands

Run these as root. On Ubuntu, Debian and RHEL, use sudo. On Alpine, use a root shell or doas.

1. Which OpenSSH package is installed. Because of backports, trust the package manager over the version banner.

apk list --installed | grep openssh

On Ubuntu or Debian, dpkg -l 'openssh-server' shows the same information. Compare the revision with the list above, or with your distribution's tracker. On recent builds sshd -V prints the upstream version. On Alpine stable branches that number looks old even when the package is fixed.

2. Which libc sshd links against.

ls -l /usr/sbin/sshd*
ldd /usr/sbin/sshd

The first command shows whether a second binary exists. The Alpine -pam package provides one named sshd.pam, so run the checks against the binary your service actually starts. In the ldd output, a line naming libc.musl means musl. A line naming libc.so.6 means glibc, and the CVE does not apply. A libpam.so.0 line means the binary was built with PAM support.

3. The effective PAM and password settings.

sshd -T | grep -Ei '^(usepam|passwordauthentication)'

sshd -T checks the configuration and prints the settings sshd will really use, after every Include file and every default is applied. This matters because the sshd_config manual gives UsePAM a default of no, while most glibc distributions set it to yes in the file they ship. On a musl system, the safe result is passwordauthentication no. On a glibc system you will usually see usepam yes.

4. Which accounts have * or ! as their password field.

awk -F: '$2 == "*" {print "field is *: " $1} $2 ~ /^!/ {print "locked !: " $1}' /etc/shadow

The shadow(5) manual says a field such as ! or * means the user cannot log in with a UNIX password. It also says a field that starts with ! is locked. Accounts with * are the ones the advisory is about. This check is useful even on a patched box, because it shows which accounts you expect to be key-only.

Treat the server as affected and patch it now if all four results line up: check 2 shows musl, check 3 shows usepam no with passwordauthentication yes, check 4 lists a * account, and check 1 shows a revision older than the fixed one.

Fix it: upgrade, then turn off password logins

On an Alpine VPS, update the package index and upgrade. Then restart sshd so the running process uses the new binary.

apk update
apk upgrade
rc-service sshd restart
apk list --installed | grep openssh

The last line should now show the fixed revision for your branch. For a container, pull the new image and recreate the container. Restarting an old container does not change its packages.

docker pull lscr.io/linuxserver/openssh-server:latest

Then recreate it with your usual docker compose up -d or docker run command.

If you cannot upgrade yet, the oss-security advisory says that setting PasswordAuthentication no mitigates the problem. Keep it off after you patch too. Password login on a public SSH port invites guessing attacks, and keys are much stronger. First, confirm that key login works from a second terminal. If you skip that step, you can lock yourself out. If key login fails, work through fixing SSH "Permission denied (publickey)" first. To generate and rotate keys, see SSH key management basics.

Many images read drop-in files from /etc/ssh/sshd_config.d/, but only if the main file has an Include line. Check before you rely on it.

grep -i '^include' /etc/ssh/sshd_config
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication'

If the first grep prints nothing, put PasswordAuthentication no near the top of /etc/ssh/sshd_config instead. For most settings, sshd uses the first value it reads, so an earlier PasswordAuthentication yes wins over a later no. sshd -t tests the file and prints an error, so sshd does not restart with a broken config. The final command must print passwordauthentication no. On Ubuntu or Debian, restart with sudo systemctl restart ssh instead of rc-service.

For the other settings worth changing on a public server, follow the SSH hardening checklist for a VPS. If this box is new, the first 10 minutes on a new VPS shows what to set up and in what order.

FAQ

Is Ubuntu or Debian affected by CVE-2026-123158?

Ubuntu and Debian build sshd against glibc with PAM. The CVE text limits the bug to musl libc with PAM disabled, so they are outside its stated scope. As of 7 November 2026, Ubuntu lists openssh as "Needs evaluation". Debian's tracker marks its stable packages vulnerable by version, with no note that explains why. Run ldd /usr/sbin/sshd and sudo sshd -T | grep -i usepam to confirm glibc and usepam yes on your own server.

Which Alpine openssh version fixes the sshole flaw?

Edge is fixed in 10.6_p2-r0. The stable branches got a backport: 3.24 in 10.3_p1-r2, 3.23 in 10.2_p1-r1, 3.22 in 10.0_p1-r11, 3.21 in 9.9_p2-r1, 3.20 in 9.7_p1-r6, 3.19 in 9.6_p1-r3, 3.18 in 9.3_p2-r4, 3.17 in 9.1_p1-r7 and 3.16 in 9.0_p1-r6. Compare the -rN package revision, not the OpenSSH version number, because the backported branches keep their old version.

Is the linuxserver/openssh-server container affected?

The image is Alpine-based and installs openssh-server-pam. It turns off password login unless you set PASSWORD_ACCESS=true. Its UsePAM value could not be confirmed from the published files, so run sshd -T inside the container. On 7 November 2026 the latest tag was 10.3_p1-r2-ls242, which matches Alpine 3.24's fixed revision. Pull it and recreate the container to get the fix.

Does turning off password authentication protect me if I cannot patch?

Yes. The oss-security advisory says PasswordAuthentication no mitigates the problem, at the cost of losing password login. Confirm that key login works first, then apply the setting. Check that sshd -T prints passwordauthentication no. Keep it off after you patch as well.

Are OpenWrt routers affected?

A stock OpenWrt image runs Dropbear, and the researcher says Dropbear is not affected. A router where OpenSSH was installed from the package feed can be affected if that build runs without PAM. Check which SSH server is installed, which libc it uses and its UsePAM value before you assume either way.