# *sshole (CVE-2026-123158): the OpenSSH flaw on Alpine that lets people in without a password, and what to do today - **Published on:** 2026-11-05 - **Category:** Security - **Original page:** https://free-linux.com/articles/openssh-sshhole-cve-2026-123158-alpine-musl OpenSSH 10.6p2 fixes a password bypass on systems with musl and no PAM, such as Alpine. Who is really affected, which versions fix it and how to review your logs. --- If you run Alpine Linux with `sshd` reachable from outside, put this down and update first: `apk upgrade -U -a`, then `rc-service sshd restart`. The second step is not optional, because upgrading the package does not replace the daemon that is already running. OpenSSH released version 10.6p2 on 5 November 2026 with an urgent fix, and Alpine published its advisory the same day along with fixed packages for every branch back to 3.16. The flaw has been named *sshole, is tracked as CVE-2026-123158 and allows login to certain accounts without knowing the password. It was found by Özgün Kültekin of Wakefield. ## What breaks There is no single guilty line. Three reasonable decisions have been fitting together badly for years: - The musl library caps the key its SHA-crypt functions accept at 256 bytes, and when something fails, `crypt()` returns the string `*` rather than a null pointer. That dates from 2012. - On Unix, a `*` in the password field has meant "this account does not log in with a password" for decades. It was assumed it could never match a real hash. - Since 2016, to avoid revealing which users exist (CVE-2016-6210), `sshd` also computes a hash in those cases, using the salt of another account on the system. Together, those pieces mean that on a system with musl and no PAM, the error result from `crypt()` can be compared with the stored `*` and accepted. That is where the headline's ten years come from: the OpenSSH piece is from 2016. Alpine's advisory puts the problematic length between 257 and 1024 bytes, while the CVE record says 256 to 1024. OpenSSH considers the root cause to lie outside its code, but has dealt with it on its side: the [patch](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482) requires the stored hash to have a minimum length before accepting the comparison, so a `*` can no longer match. ## Who is really affected Alpine considers a machine vulnerable only if all of this is true at once: - It uses the `openssh-server` package, built without PAM, or `openssh-server-pam` with `UsePAM no`. - It has `PasswordAuthentication yes`, which is the default. - An account has `*` in its password field: key-only users, directory users through musl-nscd, or the `alpine` user in tiny-cloud images. - Another local account has a `$5$` or `$6$` hash. Outside Alpine, sources mention other musl systems such as OpenWrt, Buildroot and Yocto, always depending on how they are built and configured. If you maintain your own firmware, check rather than assume. **Not affected:** glibc systems (Debian, Ubuntu, Fedora and the like), anything using PAM, systems with `PasswordAuthentication no`, containers that do not run `sshd`, accounts locked with `!`, and cloud images configured through cloud-init, which disables passwords. ## Does it really give you root? That claim has been repeated a lot on social media and needs some nuance. On Alpine, `root` has had `*` since 3.16, but the default `PermitRootLogin prohibit-password` protects it unless you have set `PermitRootLogin yes`. The real problem is accounts that can reach root. The official tiny-cloud images from 3.18.11 through 3.24.3 ship an `alpine` user with `*` and passwordless `doas`. They are safe on first boot, but stop being safe as soon as any `$6$` hash appears on the machine, for example when someone sets a console password. Nor does any Alpine box qualify: an install with no `$5$` or `$6$` hash is out of scope, and the CVSS 3.1 vector scores it 8.1 (high) with high complexity. Even so, Alpine warns that the attack needs no retries and only requires reaching the port, so this is no reason to relax. CISA records that public proofs of concept already exist.
Demonstration of the flaw. The direct root login shown is only possible with PermitRootLogin yes · Video: systemadministration.net
## Fixed versions | Alpine branch | Fixed `openssh` package | |---|---| | 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 | | 3.18 | 9.3_p2-r4 | | 3.17 | 9.1_p1-r7 | | 3.16 | 9.0_p1-r6 | Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fixed package. If you build OpenSSH yourself, you need 10.6p2 or later. ## What to do now Update and restart the service: ```sh apk upgrade -U -a rc-service sshd restart ``` If you cannot update yet, disable passwords. First check that your key works, and keep a session open until you have tested a new login: ```sh mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf sshd -t && rc-service sshd restart sshd -T | grep -i passwordauthentication ``` That directory is only read by default from Alpine 3.19 onward. On older releases, change the directive in `/etc/ssh/sshd_config`, and check any `Match` blocks too. The last command should print `passwordauthentication no`. ## How to tell if someone got in Accounts with no password should never show up with a password login, so start there: ```sh grep 'Accepted password' /var/log/messages ``` If key-only accounts or `alpine` appear, review `doas` use, newly created users, recent files and `authorized_keys`. If you cannot rule out access, Alpine recommends treating the machine as compromised, and the safe route is to reinstall it and rotate its credentials. ## How we tested this We checked the library's behaviour, not the attack: we did not make any login attempt against `sshd`. Using a small C program that calls `crypt()` with a `$6$` salt, on `alpine:3.24` (musl 1.2.6-r3) a 256-byte key gives a normal hash and a 257-byte one returns `*`. On `debian:13` (glibc), the 257-byte key still gives a normal hash and the 1024-byte one returns `*0`, an error that does not match an account's `*`. That fits what the advisories say about glibc. What this article says about versions and conditions comes from Alpine's advisory, the OpenSSH release notes and the patch code. There is more on the distribution on the [Alpine Linux](/alpine) page, and to review your own server, see our guide to [SSH keys and hardening sshd](/articles/ssh-keys-harden-sshd-linux). ## Sources - [Alpine Linux: openssh-server security advisory](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) - [OpenSSH: 10.6p2 release notes](https://www.openssh.com/txt/release-10.6p2) - [Damien Miller on openssh-unix-dev: "urgent security release: 10.6p2"](https://marc.info/?l=openssh-unix-dev&m=179388064263131&w=2) - [Fix commit in openssh-portable](https://github.com/openssh/openssh-portable/commit/4353fdc43ef646c43a8dda7025cc1a898caf1482) - [NVD: CVE-2026-123158](https://nvd.nist.gov/vuln/detail/CVE-2026-123158) - [sshhole.com: analysis by Özgün Kültekin](https://sshhole.com/)