sshhole Vulnerability Disclosed in OpenSSH on musl Systems
The sshhole vulnerability in OpenSSH on musl systems can, under certain conditions, allow access to an account without its password. The fix is included in OpenSSH 10.6p2.
On November 5, 2026, Habr reported the disclosure of the sshhole vulnerability in OpenSSH on systems using the musl Linux library. Under certain conditions, it allows someone to log into an account that does not permit password access by entering a string of more than 256 characters instead of a password. The issue had existed since 2016; the fix is included in OpenSSH 10.6p2.
When a login is possible
The vulnerability does not affect every OpenSSH installation on musl. The sshd server must run without PAM, and password authentication must remain enabled. In Alpine, the openssh-server package is configured without PAM by default; password authentication is also enabled by default. In other configurations, PAM may be disabled with UsePAM no.
There is also a condition involving user accounts. The account being targeted must have a * in its password field, while another user on the same system must have a valid password. With that combination, any password between 257 and 1024 characters is accepted for the first account. There is no need to know or guess the real password.
This matters for accounts that are normally accessed without a password: for example, users who log in only with SSH keys or users from LDAP. Root in Alpine is also listed as an example. Using keys alone does not protect against this scenario if the server still accepts password authentication and the other conditions are met.
Musl is used in Alpine, OpenWrt, Buildroot and Yocto, as well as in many Docker images. But the choice of library alone does not mean that a system can be accessed this way. According to the source, glibc-based distributions, including Debian, Ubuntu and Fedora, are not affected. Neither are systems using PAM, the dropbear server or OpenBSD's implementation of OpenSSH.
What to check on servers and in images
For developers and administrators, the first step is to identify which systems they use are running sshd and which OpenSSH builds are installed on them. This check applies both to servers and to images used to deploy a website. Once affected installations have been identified, it is worth checking separately for successful password logins to accounts that were not meant to be accessed that way.
Habr describes a way to compare an authentication entry in /var/log/messages with the user's data in /etc/shadow. In its example, the log contains Accepted password for alpine, even though that account's password field contains *. That combination warrants investigating the specific login: the log entry shows that the server accepted a password where ordinary password access was not expected.
The official Alpine images for AWS and Azure are a particular case. The default alpine user in those images has the configuration described above. That user can also run commands through doas without entering a password. Logging into that account under the conditions described therefore effectively grants root privileges. For a website owner, this is a reason to check not just the live server but also the infrastructure used to deploy the site.
The fix is available in OpenSSH 10.6p2. If upgrading is not yet possible, the article suggests disabling password logins with PasswordAuthentication no and restarting sshd. Before changing the configuration, the team should consider who and which processes rely on password authentication: this measure changes how they normally connect. The issue is not just developer access, but also how the system will be maintained after the settings change.
My view: check the setup, not the image name
I would not turn this news into a sweeping claim about Alpine's security. It is more useful to inventory systems with SSH access, check the builds in use and compare the results against the conditions for exploitation. The base image name is a starting point, but it is no substitute for checking the configuration and logs. A similar approach helps when assessing other reports of server software vulnerabilities: first establish whether they apply to your system, then decide what to do.
For me, the end goal is to upgrade to a version with the fix. Disabling password logins until then seems like a sensible temporary measure, provided it is clear in advance how administrators will connect and deployment processes will run afterward. The fix should close the vulnerability without causing an unexpected interruption to website operations.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Solutions architect
I work on web service architecture and CMS migrations. I value measurable performance and a clear upgrade path without any middle-of-the-night surprises.
All posts by the authorRelated articles
Linux Kernel Vulnerability Allows Attacks via Incoming TCP Connections
A critical Linux kernel flaw allows attackers to target servers through incoming TCP connections without a password. Server owners should check their distribution’s patch status and install the update.
The PHP Vulnerability Is Real, but Published Exploits Raise Questions
The author argues that widely shared PoCs do not demonstrate an attack against a standard PHP server. The vulnerability is real, however, and affected servers should be patched.
PHP Core Vulnerabilities Patched That Could Allow Remote Code Execution
PHP has patched core vulnerabilities that could lead to remote code execution and process memory disclosure. Website owners should check their PHP version and install the security update.
Discussion 4
Sardor N.
I’ve seen Alpine-based containers inherit sshd defaults that nobody revisited after the image was first built. In a review, I’d check the effective `UsePAM` and password-auth settings, plus the account password fields, rather than treating the image name alone as proof of exposure.
Vasilis Iacovou
I’d be careful about treating those settings as enough to establish exposure: the account password-field condition matters too, including the `*` entry and another user on the same system. Checking the image defaults is useful, but the runtime account state is where a review can still miss the actual trigger.
Oliver Lopes
That runtime account-state check is the part people tend to skip while debating image defaults. Do you know whether the `*` entry is sufficient on its own, or does the other user need a particular password-field state for the trigger to apply?
Femke Utrecht
I’d push back on treating “musl systems” as the useful risk category here: the deciding factors are sshd’s PAM and password-auth settings, plus the affected account state, not the C library label by itself. An image-name inventory can tell you where to look, but it can’t establish exposure; that takes checking the effective sshd configuration and getting to 10.6p2.