> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # SSHole (CVE-2026-123158): SSH Password Bypass on Alpine Linux > OpenSSH on musl without PAM, Alpine Linux included, accepts any overlong password. Exploited in the wild. Exposure, Alpine fixes, containers and mitigation. *Published on November 13, 2026* > [!WARNING] > > **CVE-2026-123158 — OpenSSH sshd, musl systems without PAM.** The flaw lets an attacker log in over SSH without knowing the password. It is being exploited: CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026. Debian, Ubuntu and AlmaLinux VPS are not affected. Do check your Alpine machines and containers that expose sshd. ## The bug in two sentences When built without PAM, sshd checks a password by hashing it with the C library's `crypt()` function and comparing the result with the field stored in `/etc/shadow`. With musl, `crypt()` returns `*` when the password is longer than 256 bytes: that is exactly what the field holds for accounts with no password, so the login succeeds. Affected versions: * **OpenSSH before 10.6p2**, on Linux, built with musl and without PAM; * **Alpine Linux**, every branch from 3.16 to 3.24 plus edge, according to the Alpine advisory. The fix shipped on November 5, 2026: OpenSSH 10.6p2, and fixed packages for every Alpine branch. The score published by NVD and cve.org is 8.1 (high attack complexity). Red Hat gives a preliminary 9.8. Ubuntu rates it high priority. > [!NOTE] > > GreyNoise saw a first successful exploitation on November 7, 2026, two days after the fix and a public exploit came out. The recorded sessions go from reconnaissance to reading `/etc/shadow` and creating a `server_manager` account with a passwordless `doas` rule. ## Sizing your exposure Per the Alpine advisory, a machine is exposed when **all** of the following hold: * sshd comes from the `openssh-server` package (built without PAM), or from `openssh-server-pam` with `UsePAM no`; * `PasswordAuthentication` is `yes`, the OpenSSH default; * an account has `*` as its password field: `root` in the base image, a key-only user, a directory-service user; * at least one other local account has a `$5$` or `$6$` password hash. The attacker needs the name of the target account. `root` stays protected by the default `PermitRootLogin prohibit-password`, unless another reachable account can become root, for instance through `doas`. | Profile | Exposure | Action | | - | - | - | | Debian, Ubuntu, AlmaLinux, Rocky Linux, RHEL VPS (system sshd) | Not affected | Nothing to do on the host | | Alpine running sshd with `PasswordAuthentication yes`, reachable from the Internet | **Critical** | Update today and restart sshd | | Alpine container running sshd with its port published | **Critical** | Rebuild the image with the fixed package; if you can't, turn passwords off | | Alpine tiny-cloud image, 3.18.11 to 3.24.3 | **Critical** once any password is set | Update or turn passwords off on every instance | | Alpine with `PasswordAuthentication no`, or `openssh-server-pam` with `UsePAM yes` | Not affected | Update at your next maintenance window | | Alpine container without sshd | Not affected | Nothing to do | | Embedded device on musl without PAM (Yocto images, for example) | Possible | Ask the vendor | > [!NOTE] > > The official tiny-cloud images (qcow2, VHD, AMI) ship an `alpine` user with no password and passwordless `doas`. They are safe on first boot, and become exploitable as soon as a password hash shows up on the machine, such as a console password set by the admin. ## Debian, Ubuntu, AlmaLinux VPS: the host is not exposed Ubuntu states that its OpenSSH is linked against glibc and uses PAM, so it is not vulnerable on any release. Red Hat says its products are not affected. Debian rates the flaw "unimportant" for its package and only carries the fix in unstable and forky. Your VPS's own sshd needs no action. What you should check are the Alpine containers running on it. ```bash theme={null} # Running containers: name, image, published ports docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}' # For a container publishing an SSH port: distribution and whether sshd runs docker exec cat /etc/alpine-release docker top | grep sshd ``` A container that answers with an Alpine version number and runs sshd falls under the next section. The same goes for a Kubernetes pod built on an Alpine image that starts sshd. ## Updating Alpine Linux The fix is an update of the `openssh` package, followed by an sshd restart. **Updating alone does not replace the daemon that is already running.** | 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` | Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fixed package. Alpine also published packages for branches that no longer get regular updates, all the way back to 3.16. ```bash theme={null} # Alpine: install the fix, then restart sshd apk upgrade -U -a rc-service sshd restart # Check the installed version apk list -I | grep openssh ``` ### Docker containers If you own the image, rebuild it on an Alpine release that includes the fix (3.21.10, 3.22.8, 3.23.8, 3.24.4 or later), then recreate the container. ```bash theme={null} # Rebuild, pulling the latest base image docker build --pull --no-cache -t . ``` In the meantime, you can patch a running container: ```bash theme={null} docker exec apk upgrade -U -a docker restart ``` That fix is lost the next time the container is recreated: only a rebuilt image lasts. For a third-party image, wait for the publisher's fixed release and apply the mitigation below until then. ## Mitigation until you can patch Alpine recommends turning password authentication off. Before you start, make sure [SSH key](https://help.onetsolutions.net/vps/ssh-keys) login works, and keep your current session open until you have tested a new login. Run as root: ```bash theme={null} # Drop-in configuration file (read by Alpine from 3.19 onward) mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf # Flip every PasswordAuthentication line to no, add one at the top, keep the original as .bak sed -i.bak -e '1i PasswordAuthentication no' \ -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \ /etc/ssh/sshd_config # Validate the configuration and restart sshd sshd -t && rc-service sshd restart ``` The `sed` command also changes lines inside a `Match` block. ## Verifying the mitigation ```bash theme={null} sshd -T | grep -i passwordauthentication ``` Expected: `passwordauthentication no`. After an update, compare the output of `apk list -I | grep openssh` with the table entry for your branch. ## Looking for traces Exploitation has been seen since November 7. On an exposed Alpine machine, look for password logins on accounts that have no password: ```bash theme={null} # Logins accepted by password grep 'Accepted password for' /var/log/messages # Accounts with no password (* field) awk -F: '$2 == "*" {print $1}' /etc/shadow ``` An `Accepted password for` line on one of those accounts (`root`, `alpine`, a key-only user) means an intrusion. Also review `doas` use and recently created accounts, files and `authorized_keys` entries. A `server_manager` account you did not create is an indicator reported by GreyNoise. If you cannot rule out a login, treat the machine as compromised. ## Rolling back the mitigation Once the fixed package is installed, if you need passwords back: ```bash theme={null} rm /etc/ssh/sshd_config.d/00-no-passwords.conf cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config sshd -t && rc-service sshd restart ``` ## What next? Key-only login remains the best setup for an exposed server: keep `PasswordAuthentication no` even after the update. For another recent OpenSSH flaw, read [regreSSHion (CVE-2024-6387)](https://blog.onetsolutions.net/en/regresshion-cve-2024-6387.md). For any technical question, open a ticket from your [OnetSolutions customer area](https://help.onetsolutions.net/console/support). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.