--- title: "Alpine OpenSSH flaw: an oversized password opens locked accounts" description: "Disclosed on 5 November, the \"*sshole\" flaw reportedly lets attackers open an SSH session on password-disabled accounts on musl-based Linux, with Alpine first in line. Alpine's official cloud images on AWS and Azure are said to be exposed, and root access is possible." canonical: https://inyourgeek.com/en/articles/2026-11-06-faille-openssh-sur-alpine-un-mot-de-passe-trop type: article author: "Sébastien Soulier" publisher: "InYourGeek" language: en datePublished: 2026-11-06 dateModified: 2026-11-06 section: "Security" tags: ["openssh", "alpine", "musl", "linux"] --- # Alpine OpenSSH flaw: an oversized password opens locked accounts > Disclosed on 5 November, the "*sshole" flaw reportedly lets attackers open an SSH session on password-disabled accounts on musl-based Linux, with Alpine first in line. Alpine's official cloud images on AWS and Azure are said to be exposed, and root access is possible. November 6, 2026 · Security · 3 min Security researcher Ozgun Kultekin published the details of a flaw in OpenSSH on 5 November 2026. It affects Linux distributions built on the musl C library. According to [Bleeping Computer](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/), which is the only source available so far, the bug has been around since 2016. It was reportedly found with the help of AI agents. They ran about 17,600 authentication tests, mixing OpenSSH configurations, malformed password hashes and oversized passwords. That is exactly the kind of mind-numbing grind nobody wants to do by hand. ## When a star matches a star On Linux, you block password login for an account by replacing its hash with an asterisk (`*`) in `/etc/shadow`. An asterisk isn't a valid hash, so in theory no password can ever match it. It's the No Entry sign of account management. The problem apparently goes back to a fix from 2016. To stop attackers from working out valid usernames by timing the server's responses (CVE-2016-6210), OpenSSH now computes a hash even for accounts that have no usable one, including accounts locked with `*`. The catch is that on musl, the `crypt()` function also returns `*` when it fails. One way to make it fail is to submit a password longer than its 256-byte limit. So all an attacker needs is a password that's too long. OpenSSH compares the `*` returned by `crypt()` with the `*` on file, sees that they match, and opens the session. It's like a bouncer who lets you in because your ID card says "ID card". The flaw doesn't let anyone bypass the password of an account with a valid hash. It only affects accounts locked with an asterisk. ## Who's exposed According to the researcher, an attack only works if all of these conditions are true: - OpenSSH is running on a musl system: Alpine Linux, OpenWrt, Buildroot or Yocto; - PAM authentication is disabled, which is the default in Alpine's openssh-server package; - SSH password authentication is enabled; - at least one account has an asterisk as its hash, and another account has a valid hash. The official Alpine Linux cloud images on AWS and Azure are the most sensitive case. By default, they ship with an `alpine` account that is affected by the flaw. That account also has passwordless `doas` privileges, so an attacker could get root access. One long string is enough to turn a locked door into a master key. Systems based on glibc, such as Debian, Ubuntu and Fedora, aren't vulnerable. Neither are systems that go through PAM authentication. If you run an OpenWrt, Buildroot or Yocto machine with an SSH server switched on, the same checks apply as for Alpine. ## Check and patch The fix is in OpenSSH 10.6p2. On Alpine, you update with: ``` apk upgrade openssh ``` If you can't update straight away, turn off SSH password authentication with the `PasswordAuthentication no` directive in the server configuration, then restart the SSH service. This removes one of the conditions the attack needs. ## Look for footprints The researcher also recommends going through your SSH authentication logs. You're looking for password logins on accounts that should never accept one. On Alpine, this command lists successful password logins: ``` grep "Accepted password" /var/log/messages ``` If you see a successful login for the `alpine` account, check its password field: ``` grep '^alpine:' /etc/shadow ``` If that field holds an asterisk but the logs show an accepted password login, the flaw may have been exploited. The same logic applies to any other account locked this way. For ten years, "this account is locked" and "musl's crypt() just failed" were written with the same single character. A footnote symbol was all it took to open the front door. ## Sources - [OpenSSH flaw lets attackers log into password-disabled Linux accounts](https://www.bleepingcomputer.com/news/security/openssh-flaw-lets-attackers-log-into-password-disabled-linux-accounts/) — bleepingcomputer.com _Article written with AI assistance from the cited sources, reviewed and approved by a human before publication._ --- Equivalent HTML page : https://inyourgeek.com/en/articles/2026-11-06-faille-openssh-sur-alpine-un-mot-de-passe-trop Published by InYourGeek — https://inyourgeek.com/en/a-propos Method and safeguards : https://inyourgeek.com/en/methode All articles : https://inyourgeek.com/en/archives