Key Takeaways
- A long-standing vulnerability affects Alpine Linux and several other Linux distributions.
- The flaw is rated as critical, enabling remote unauthenticated access.
- Apply patches immediately and restart affected services.
The worst-case scenario for a Linux server is an attacker gaining full control simply by connecting to the Secure Shell (SSH) port. That is precisely what occurred with Alpine Linux, the widely used lightweight server distribution. The incident took place only days after Alpine addressed a separate security issue in its GitLab implementation.
How the Attack Works
Security engineer Gregory Bryant detailed the issue in a LinkedIn post:
Most authentication bypasses come from complex logic chains, but yesterday’s Alpine Linux OpenSSH vulnerability (CVE-2026-123158) comes down to a single character: *.”
If you run Alpine Linux (or another musl-based distro) with the default openssh-server package (no Pluggable Authentication Modules (PAM)) and PasswordAuthentication enabled, an attacker can log into password-disabled, or key-only accounts simply by sending a password between 257 and 1024 bytes long.
That is all that is required.
Alpine Linux is not the only operating system that uses musl, a lightweight version of the standard C library (libc). Other operating systems that use musl and are potentially vulnerable include Adélie Linux, Void Linux, Sabotage Linux, OpenWrt, an Android variant, and the Yocto Project, which is used to build embedded Linux distributions.
Wind River, which produces the commercial embedded Linux distro Wind River Linux, is also looking into the issue. A company representative said, “Wind River takes security seriously. We are actively reviewing the reported vulnerability and assessing its potential impact. We will take appropriate action as needed.”
Behind the scenes, when OpenSSH is built without PAM, it verifies passwords by hashing the password attempt using the C library’s crypt() function. It then compares the result to the account’s stored password field. So far, so good.
But when a key is longer than 256 bytes, musl’s crypt() function returns the string * as an error indicator. That is also what the password field holds for any account with no password, such as a key-only account. Thus, the “hash” matches and the login succeeds, and the attacker walks in.
To exploit it, an attacker only needs the name of such an account. The attacker also needs at least one other account on the machine with a 5 or 6 password hash, and then to send a password of 257 to 1,024 bytes. According to Alpine, one user with a password is enough to make every passwordless account accessible.
In Linux systems that use glibc’s crypt(), which is almost all of them, the same attempt would return NULL on error, which sshd already rejects, so Debian, Ubuntu, Fedora, etc., aren’t affected.
According to *sshole, the group that uncovered the problem, this is a side effect that has been hiding since 2016.
Who’s Exposed
Alpine said every release it checked is affected: 3.21 through 3.24, edge, and the older 3.16 to 3.20 branches. Exposure requires the following:
- The openssh-server package, which is built without PAM, or openssh-server-pam with UsePAM no.
- PasswordAuthentication set to yes, which is the OpenSSH default.
- An account with * as its password field, and another account with a 5 or 6 hash.
Root is not directly exposed in most cases. It has shipped as root:* in the base image since about Alpine 3.16, but OpenSSH’s default PermitRootLogin prohibit-password blocks it. Another account that can become root, for example through doas, still gives an attacker a route to root.
Alpine singled out its official tiny-cloud images, versions 3.18.11 through 3.24.3, as especially vulnerable. These ship with an alpine user with a * password field and passwordless doas. They are safe on first boot but become exploitable once any 6 hash exists on the machine. That can happen when an administrator sets a console password or when user data adds a user with a hashed password, which means, essentially, all of them.
Alpine said these are not affected:
- Containers that do not run sshd.
- Systems with password authentication disabled.
- Systems using openssh-server-pam with UsePAM yes.
- Locked accounts with! in the password field.
- Cloud images configured through cloud-init, which writes PasswordAuthentication no.
The Fix
Alpine released 3.21.10, 3.22.8, 3.23.8 and 3.24.4 on Thursday, with the OpenSSH fix among the security changes. It also published fixed packages for each release back to 3.16. Alpine 3.21 reached end of support on Nov. 1.
The just-released OpenSSH 10.6p2 avoids the problem in sshd. Alpine’s stable branches carry a patch for the same problem. You should run apk upgrade -U -a and then restart the daemon with rc-service sshd restart. Alpine stressed that upgrading the package does not replace the running daemon. Anyone who cannot update should set PasswordAuthentication no and restart sshd, after confirming that key login works.
To check for an attack, Alpine told administrators to search /var/log/messages for “Accepted password for” lines that name an account with no password. It also advised reviewing dedicated OpenBSD application subexecutor (doas) use and recently created users, files, and authorized keys. “If you cannot rule out a login, treat the machine as compromised.”
