Many people in cybersecurity may be losing a few more hairs. It recently came to light that when you connect over SSH on Alpine Linux, as long as you enter a password longer than 256 characters, you can successfully log into the system with root privileges. An attacker doesn’t need to know any password; a single connection gets them in, with no retries needed and no lockout. This one, named *sshole the vulnerability (genuinely funny) was disclosed by security researcher Özgün Kültekin on November 5, 2026, on the explainer website he set up himself sshhole.com Summarize it in one sentence: “Yes, any password. Yes. Yes, I know. Yes.”
The OpenSSH team released version 10.6p2 the same day to patch this flaw, and Alpine Linux also rolled out updated packages for all of its distributions. OpenSSH project member Damien Miller told the media that no attacks exploiting this vulnerability have been reported so far. The conditions for triggering the vulnerability are quite stringent; the root cause lies at the boundary between the C library and the SSH server, involving a side effect of a fix that has persisted for nearly a decade.
Which systems does the vulnerability affect?
Alpine Official Security BulletinThe listed affected conditions must all be satisfied simultaneously for a match:
- musl libc systems: Alpine Linux, OpenWrt, Buildroot, Yocto. This is a typical environment where PAM is not enabled when OpenSSH is compiled.
- PAM disabledAlpine’s
openssh-serverThe package does not compile PAM by default. If you instead useopenssh-server-pamand setUsePAM yes, it will not be affected PasswordAuthentication yesAdministrators usually don’t change OpenSSH’s defaults.- The password field for at least one account is
*: means that the account has no password set. This is common in Alpine,rootSince version 3.16, it has been in the base image.root:*; useadduserUsers who were created but not given a password, as well as directory service accounts accessed via musl-nscd, also qualify. - At least one local account has
$5$or$6$password hashIn other words, it’s an account that actually has a password set.
The last condition is the most critical. As long as there is one account with a password set on the machine, all accounts without passwords will be exposed as well; an attacker only needs to know one of the account names to log in. Alpine’s official testing results show that affected versions cover 3.16 through 3.24 and all versions of the edge development branch. (This vulnerability only occurs on Alpine Linux)
As for the root account, OpenSSH’s default PermitRootLogin prohibit-password blocked direct login; only when set to PermitRootLogin yes Only then would it be directly exposed. But this protection cannot stop privilege-escalation paths. Official Alpine tiny-cloud images (qcow2, VHD, and AMI formats) from 3.18.11 to 3.24.3 all include a built-in password field whose value is * The provided text “的” is a grammatical particle in Traditional Chinese and cannot be translated on its own without context. Please provide the full sentence or phrase. alpine account, and has passwordless doas Permissions. These images are secure on first boot; once an administrator sets the console password, or user-data Join the band hashed_passwd the user’s machine will be compromised and the attacker will log in alpine and then through doas Escalate to root.
Why did no one find out for ten years?
Kültekin lists several reasons on his own explanation page: a fresh installation and a machine with no password set will not be affected; in the shadow file is * account needs to fail once before it is triggered; OpenSSH is tested on OpenBSD and glibc systems, and the musl path is not in scope; most distributions use PAM, and PAM for * The field doesn’t call crypt at all.
He also compiled several records of near misses on the page. In July 2013, a Debian developer asked glibc to copy musl’s asterisk behavior; six years later, Debian switched to libxcrypt, and that library returns *0, it was just one character away from closing this bug. In late December 2024, the musl mailing list discussed busybox’s passwd Made an error with a 257-character password—same limitation, same asterisks, but no one connected it to sshd.
The closest occurrence happened on October 30, 2026, when an OpenSSH security review happened to fix pick_salt() the problem. Kültekin wrote that the bug was four lines below that function, and he only found it four days later.
Repair Methods and Version Selection
The fix in OpenSSH 10.6p2 makes sshd refuse to compare when the password field is shorter than four characters. The official description calls this change a workaround and explicitly states that the root cause lies outside sshd. The vulnerability was reported by Özgün Kültekin of Wakefield.
Alpine has built packages with the same patch for every branch: edge branch 10.6_p2-r0, 3.24 branch 10.3_p1-r2, 3.23 branch 10.2_p1-r1, 3.22 branch 10.0_p1-r11, 3.21 branch 9.9_p2-r1, down to 9.0_p1-r6 on the 3.16 branch. Among them, 3.21 reached end of support on November 1, 2026.
The official notice warns of an easy pitfall: updating the package alone will not restart the running sshd; you must do it separately. rc-service sshd restart. Administrators who cannot update immediately can set PasswordAuthentication no Disable password login; the Alpine announcement provides guidance on creating a drop-in configuration file and checking. sshd -T Complete output instructions.
To confirm whether it has been exploited, the notice recommends checking. /var/log/messages appears in Accepted password for but corresponds to records of passwordless accounts, for example alpine、root or users who use only a key. The announcement also stated outright that if a login cannot be ruled out, the machine should be treated as compromised.
AI agents participate in vulnerability discovery
When Kültekin described his discovery process, he mentioned that he built sshd in multiple configurations, including glibc, musl, with and without PAM, and with and without shadow variants, and ran about 17,600 deliberately crafted login tests covering abnormal hash values, corrupted accounts, and overly long passwords. On the explanation page he also added: “Sorry I said ‘I’; it was a large group of AI agents running it.”
The OpenSSH team’s attitude toward this vulnerability is also worth recording. In the release notes, Miller mentioned that the team has recently received a large number of security vulnerability reports produced by AI models or with AI assistance, and that the team is currently adopting a more frequent release cadence to get fixes to users as quickly as possible rather than accumulating them for the next scheduled version. His reasoning is that there have already been cases where, after an AI tool found a certain bug, another researcher independently reproduced the same issue, and attackers who do not report to open source projects can also find it. He also mentioned that he has recently seen AI agents repeatedly find the same vulnerability within a few hours, so a long confidentiality period actually benefits attackers more.
Conclusion
If you are not an Alpine Linux user, you don’t need to worry too much either. There is no problem with the Linux kernel, and OpenSSH is not the source of the vulnerability either; the trigger point is musl’s crypt() Design choices in error handling overlap with the side effects of OpenSSH’s fix for username enumeration. The impact is limited to the musl ecosystem; glibc systems such as Debian, Ubuntu, and Fedora, as well as all environments that use PAM authentication, are unaffected.
But downplaying it is equally inappropriate. Although the trigger conditions are stringent, they cover all versions of Alpine, a distribution widely used for containers and cloud images, and what is built into the tiny-cloud image alpine Account with passwordless authentication doas, giving the attacker root privileges. A single connection succeeds, no retries are needed, and it does not trigger blocking mechanisms; these characteristics make it particularly useful in penetration testing and automated scanning.
The patching work has been completed. OpenSSH 10.6p2 and the packages for all Alpine branches are ready, and no reports of actual attacks have been received officially. For administrators, what remains is a routine task that requires no hesitation: update the packages, restart sshd, and confirm sshd -T The output meets expectations.
Source: *sshole · sshhole.com
Source: KOCPC Chinese