Ing. Calogero Bono
On November 5, 2026, OpenSSH 10.6p2 was released, fixing a bug nicknamed «*sshole». It affects SSH servers on Linux that use the musl library, such as Alpine Linux, with PAM disabled. Anyone who reaches the SSH port can log in to an account without a password by sending a very long password. It matters because a single connection is enough, and Alpine's official cloud images can grant root access.
A few terms before we get into the facts. musl is a C library alternative to glibc, used by Alpine, OpenWrt, Buildroot and Yocto. crypt() is the function that turns a password into its hash. PAM is Linux's modular authentication system. /etc/shadow is the file that stores password hashes. doas is a tool, similar to sudo, for gaining root privileges.
How does the *sshole bug work?
A Linux account without a password has an asterisk in place of the hash in /etc/shadow. No password should open it. According to BleepingComputer, a 2016 change to OpenSSH, made to fix CVE-2016-6210 on user enumeration, causes the hash to be computed for these accounts as well.
This is where musl comes in. As the Alpine advisory explains, musl's crypt() returns * as an error signal if the key exceeds 256 bytes. That asterisk matches the one stored in the account, and the comparison succeeds. Researcher Özgün Kültekin says the flaw has existed since 2016.
Who is really at risk?
Several conditions must hold together. According to Alpine, the openssh-server package is built without PAM, or openssh-server-pam is used with UsePAM no. PasswordAuthentication must be enabled, as it is by default. There must be an account with * and at least one other with a $5$ or $6$ hash. A single user with a password is enough to make all the others reachable.
Alpine verified versions from 3.21 to 3.24 and edge, plus the older 3.16-3.20. Containers without sshd, systems with PasswordAuthentication no and systems with PAM enabled are not affected. Debian, Ubuntu and Fedora, which use glibc, are not vulnerable, according to BleepingComputer.
Why do Alpine's cloud images raise concern?
The official tiny-cloud images, from 3.18.11 to 3.24.3, have an alpine user with password * and doas without a password. Alpine notes they are safe on first boot. They become exploitable when a $6$ hash appears, for example if an administrator sets a console password or if user-data adds a user with hashed_passwd.
At that point the attacker gets a shell as alpine and, using doas, becomes root. Images configured with cloud-init, which writes PasswordAuthentication no, are not hit. For root, the default PermitRootLogin prohibit-password protects only in a direct way.
How do you fix it and how do you check for an attack?
The fix is in OpenSSH 10.6p2. On Alpine, run apk upgrade -U -a, then restart sshd, because the update does not replace the daemon already running. Alpine has published corrected packages back to 3.16, including for releases no longer supported.
If you cannot update, set PasswordAuthentication no and restart sshd, after verifying that key-based login works. To look for traces, check /var/log/messages for «Accepted password» lines for accounts without a password. Alpine adds that if you cannot rule out access, the machine should be considered compromised. For account permissions, the guide on Linux permissions also applies.
Limits to know
Alpine notes that no CVE had been assigned at the time of publication. OpenSSH writes that the cause lies outside sshd, but it is exploitable through sshd and is avoided there. There is no data on real attacks in progress. The claims about the 17,600 tests run with AI agents come from the researcher, reported by BleepingComputer, and have not been independently verified.
What changes for those working in digital
If you manage Alpine servers, OpenWrt routers or embedded systems built with Yocto and Buildroot, check whether sshd allows passwords and whether there are accounts with *. Many people run Alpine in containers without sshd and are not affected. Anyone running cloud machines from the tiny-cloud images must verify every instance already running. A managed server with regular updates reduces this kind of risk, as we discuss on the page about hosting and managed servers. It is also worth keeping an eye on the related case of AI-generated exploits, which we covered in this article.
Our take
The case shows how fragile the boundary between components that trust each other can be. OpenSSH added a legitimate defense in 2016, musl chose a common error value, and together they opened a door for ten years. It is also striking that the bug was found using AI agents. OpenSSH itself warns that bugs found with AI are often rediscovered by others, so waiting is a risk. The most solid remedy remains the same as always – keys instead of passwords.
Frequently asked questions
Are Debian and Ubuntu vulnerable to *sshole?
No. They use glibc, not the musl library. BleepingComputer confirms that systems with PAM authentication are not vulnerable, but Alpine specifies that openssh-server-pam with UsePAM no is not vulnerable, while with UsePAM yes it is not either.
Is it enough to update the openssh package?
No, you also need to restart sshd. Alpine notes that the update does not replace the daemon already running, so the vulnerable version would stay active.
Can I protect myself without updating?
Yes, as a temporary measure. Set PasswordAuthentication no in the sshd configuration and restart the service. First verify that key-based login works.
Is root also exposed?
Only in some cases. With PermitRootLogin prohibit-password, the default, root cannot be reached directly. It becomes reachable if PermitRootLogin yes is set or if another user can become root, for example with doas.
Is there a CVE for this bug?
Not yet, according to Alpine. The advisory says that at the time of writing no identifier had been assigned. The reference is the OpenSSH 10.6p2 release notes.
What to watch after OpenSSH 10.6p2
OpenSSH has announced more frequent releases to get fixes to users faster. The bug leaves some open questions to follow.
- Check whether a CVE will be assigned and whether your scanning tools will recognize it.
- Verify when firmware vendors based on OpenWrt, Buildroot and Yocto will publish updates.
- Prepare a routine to install OpenSSH minor releases without waiting for scheduled versions.
