On November 5, 2026, the OpenSSH project released version 10.6p2 to fix a critical authentication bypass. The flaw, now tracked as CVE-2026-123158 and known as "SSHole," lets an attacker log in to accounts that have no password. The attacker needs only network access, a valid account name, and a password between 257 and 1,024 bytes long.
The flaw affects a specific configuration: Linux systems built on the musl C library that check passwords without PAM (Pluggable Authentication Modules). Alpine Linux, a common base for containers and cloud images, ships this configuration by default. Exploitation attempts were reported within hours of disclosure.
This article explains how the flaw works, which systems are exposed, and what to do now. It also explains how Terra Platform™ tests customer assets for this exposure.
What Is SSHole?
SSHole is a password authentication bypass in the OpenSSH server (sshd). It comes from how sshd works with musl, the C library that Alpine Linux and other lightweight distributions use.
The OpenSSH project rates the flaw critical. The NVD record for CVE-2026-123158 lists a CVSS 3.1 base score of 8.1 (High). The OpenSSH maintainers state that the root cause is outside sshd. Version 10.6p2 adds a workaround in sshd that blocks the attack, as the OpenSSH 10.6p2 release notes describe. Özgün Kültekin of Wakefield reported the flaw.
How the Bypass Works
Without PAM, sshd checks a password itself. It hashes the password attempt with crypt(), a C library function, and compares the result with the stored field in /etc/shadow.
An account with no password has only * in that field. That field is too small to store a salt. Since a 2016 OpenSSH change that fixed a username enumeration flaw (CVE-2016-6210), sshd borrows the salt of another account that has a real hash. This keeps response times equal for valid and invalid users.
For $5$ (SHA-256) and $6$ (SHA-512) hashes, musl's crypt() refuses passwords longer than 256 bytes. To signal the error, it returns *. That output matches the stored *, so sshd accepts the login. The upper limit of 1,024 bytes is the maximum password length in sshd.
Each behavior is reasonable alone. Together, they create a bypass that has existed for about ten years. The attack does not need brute force. According to the Alpine Linux security advisory, it succeeds on every attempt with a single connection.
Who Is Exposed?
The Alpine advisory lists four conditions. A server is exposed only when all four are true:
- The server runs the openssh-server package, which Alpine builds without PAM, or runs openssh-server-pam with UsePAM no.
- PasswordAuthentication is yes. This is the OpenSSH default.
- At least one account has * as its password field, which means it has no password.
- At least one other local account has a password hash that starts with $5$ or $6$.
The attacker must also know the name of an account with no password. On Alpine, these accounts are common. They include key-only users, users from a directory service through musl-nscd, root (which has shipped as root:* in the base image since about Alpine 3.16), and the alpine user in official tiny-cloud images.
The default PermitRootLogin prohibit-password setting blocks direct root logins. But an attacker who gets access to another account can escalate. The tiny-cloud images from 3.18.11 through 3.24.3 give the alpine user passwordless doas. These images are safe at first boot. They become exposed when any $6$ hash exists on the machine, for example after an administrator sets a console password. An attacker can then log in as alpine and become root.
Systems That Are Not Affected
The OpenSSH project states that non-Linux systems, glibc-based Linux systems, and systems that check passwords through PAM are not affected. The Alpine advisory adds that these are also safe: systems with PasswordAuthentication no, containers that do not run sshd, and cloud images set up through cloud-init, which writes that setting.
The researcher's technical write-up names OpenWrt, Buildroot, and Yocto as other musl-based systems to check. OpenWrt uses Dropbear for SSH by default, which is not affected. Embedded and appliance builds need a review per product.
How to Remediate
Act now. It was reported that the threat intelligence firm Previdian saw the first exploitation attempt less than nine hours after the CVE was published. Previdian also confirmed root access on an Alpine Linux honeypot.
Update and Restart
On Alpine, update the package and restart sshd. The package update alone does not restart the running daemon.
- Update the packages: apk upgrade -U -a
- Restart the server: rc-service sshd restart
Point releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4 include the fixed package. Alpine also published fixed packages for branches 3.16 through 3.21, which are past end of support. Instances started from older images still need the update.
If you build OpenSSH yourself on musl without PAM, upgrade to 10.6p2. Rebuild container images from patched base images, then redeploy them.
If You Cannot Update Yet
Disable password authentication:
- Make sure that SSH key login works. Keep your current session open until a new login succeeds.
- Set PasswordAuthentication no. Change every instance, including lines in Match blocks.
- Validate the configuration with sshd -t, then restart sshd.
- Run sshd -T | grep -i passwordauthentication. The output must be passwordauthentication no.
Look for Signs of Compromise
Search /var/log/messages for sshd lines that read Accepted password for an account with no password, such as alpine, root, or a key-only user. On exposed machines, also review doas use, recently created users, files, and authorized keys. The Alpine advisory is clear: if you cannot rule out a login, treat the machine as compromised.
For long-term hardening, NIST IR 7966 gives guidance on how to manage SSH access, including how to control and inventory SSH keys.
How Does Terra Protect Customers?
Patch guidance tells you what to do. A harder question is where you are exposed. Exposure depends on build options, account state, and configuration on each host. Many teams do not know which internet-facing systems run Alpine-based sshd with password logins enabled.
Terra customers with continuous External Network pentesting do not need to wait. Terra's AI agents already test their in-scope, internet-facing assets for exposure to CVE-2026-123158. Customers do not need to open a request or change scope. Confirmed findings appear in Terra Platform™ with the evidence and remediation steps that security teams need to act.
Why Does Continuous Testing Matter?
SSHole shows a clear pattern. The bug existed for about ten years. Exploitation attempts started within hours of disclosure. In his release announcement, OpenSSH maintainer Damien Miller said the team now sees long embargoes as dangerous because AI agents have recently found the same bugs again, sometimes within hours.
A point-in-time pentest cannot keep up with this cycle. An annual test does not tell you whether a flaw disclosed on Thursday affects your perimeter on Friday. Continuous, agentic pentesting tests assets as new threats emerge. Terra's agents operate inside a customer-approved scope, with human-in-the-loop workflow gates. This lets security teams validate real exposure quickly and safely and spend their time on remediation instead of discovery.
Next Steps
If you are a Terra customer, review your External Network findings in Terra Platform™, or contact your Terra team for questions about scope.
If you are not a Terra customer, talk to our team to see how continuous, agentic pentesting validates your external attack surface as new threats emerge.
