Skip to main content
Huaqi Future Huaqi Future Co., Ltd.
Contact us

Breaking Brief

*sshole: OpenSSH login bypass hits some Alpine Linux setups

In short, any company that runs servers or devices on Alpine Linux and exposes SSH should update OpenSSH and restart sshd today, or, if it cannot update, turn off password logins. Mainstream Linux setups are not the main target, and a system that does not meet the conditions below is not affected. The facts below were checked against the original pages from OpenSSH, Alpine Linux and Ars Technica on November 6, 2026.

Published November 6, 2026

1. What happened

On November 5, 2026, OpenSSH released Portable OpenSSH 10.6p2. Its release notes describe a critical workaround for a password-authentication bypass that affects some Linux systems when sshd is built and run with PAM support disabled. The team says it considers the root cause to be outside sshd, but because the bug is exploitable through sshd, it made sshd avoid it. The bug was reported by Özgün Kültekin of Wakefield (OpenSSH 10.6p2 release notes).

The same day, Alpine Linux published an advisory saying an attacker who can reach the SSH port can log in without knowing any password, in a single connection, every time, with no retries. The attacker needs the name of an account whose password field is "*" (a common setting for key-only accounts), the machine must have at least one other account with a $5$ or $6$ password hash, and the attacker sends a very long password of 257 to 1024 bytes. No CVE identifier had been assigned at the time of the advisory (Alpine Linux advisory).

2. Who is affected

According to the Alpine advisory, affected systems run openssh-server built without PAM, or openssh-server-pam with UsePAM no, and still have PasswordAuthentication at its default of yes. Releases 3.21 through 3.24 and edge are affected, as are the older 3.16 to 3.20 that no longer get regular updates. Containers that do not run sshd, and systems with PasswordAuthentication no, are not affected. Root is protected by the default PermitRootLogin prohibit-password, but that does not help if another reachable account can become root, for example through doas (Alpine Linux advisory).

Ars Technica reports that the problem arises from the interaction between OpenSSH and musl, the lightweight libc that Alpine uses. It notes that the official Alpine image on Docker Hub has more than a billion downloads and that Alpine is widely used in routers, smart TVs, industrial controllers and other embedded devices, many of which are hard or impossible to update. Which other distributions are affected is not yet known. Musl developer Rich Felker takes the position that this is not a musl bug but erroneous use by the caller, and says musl plans changes in an upcoming release (Ars Technica).

Our view We think the companies hurt most are those that do not know they use Alpine at all. What sits inside Docker images, routers, NAS boxes and servers built by an agency is often invisible to the company that ordered them. If SSH is open to the internet and password login is on even though the company believes it uses keys only, someone could get in before anyone notices and take customer data or order records. The company would then face an investigation and explanations to business partners at the same time. We recommend asking your contractors this week for a list of the devices that can be reached over SSH from outside.

3. Why it matters: fixes now arrive far more often

The OpenSSH 10.6p2 release notes say the team has recently received a large number of security reports, many of them findings from AI models or made with AI assistance. It adds that there have been cases where a bug found by AI was later found independently by another researcher, which suggests adversaries who do not report bugs can find them too. For that reason the team says it will, for now, make more frequent releases instead of batching fixes (OpenSSH 10.6p2 release notes). None of the original pages we checked says this particular bug was found with AI.

Our view More frequent fixes mean that companies that treat updating as a once-a-year batch job will spend longer unpatched. This case also shows that updating the package without restarting sshd leaves the old program running. Whether a company has a named person and a procedure that includes the restart will separate it from its competitors. Those without one will repeat the same scramble each time another fix appears, and every week left unpatched is a week an open SSH door stays exposed.

4. What small businesses should check now

  • Ask your contractors or agency for a list of servers, cloud containers, routers and NAS devices that can be reached over SSH from the internet
  • Check which of them run Alpine Linux, including Docker images that are based on Alpine
  • On Alpine, update openssh and then restart sshd; updating the package alone does not replace the running daemon
  • If you cannot update right away, set PasswordAuthentication no in the sshd configuration and restart; Alpine says either step closes the hole
  • For embedded devices that cannot be updated, check whether SSH is exposed to the outside and, if so, discuss closing it with your contractor

Our outlook

Over the next six months to two years, we expect fixes to core software such as OpenSSH to arrive more often and at shorter intervals, given that OpenSSH itself says it is moving to more frequent releases. If, in the same period, AI that searches for and compares suppliers on behalf of consumers and business partners becomes common, sites that are down and companies that cannot explain their security are likely to be dropped at the comparison stage. The companies that keep a device inventory, run updates and restarts on a fixed procedure and keep the number of externally open entry points to a minimum will keep being chosen by both partners and AI. Now is the time to lay that groundwork.

Questions this article answers

What is *sshole, and does it affect our servers?

It is the nickname for a flaw, fixed in OpenSSH 10.6p2 on November 5, 2026, that lets an attacker log in over SSH without a password. It affects setups such as Alpine Linux that use OpenSSH without PAM together with musl, and applies when PasswordAuthentication is still yes. If you do not use Alpine, you are normally not affected.

What should we do if we cannot update right away?

Alpine's advisory says that setting PasswordAuthentication no in the sshd configuration and restarting closes the hole just as updating does. When you do update, restart sshd as well, because updating the package alone does not replace the running daemon.

Sources

  1. OpenSSH: Portable OpenSSH 10.6p2 release notes (2026-11-05)openssh.com
  2. Alpine Linux: Security advisory: openssh-server password authentication bypass (2026-11-05)alpinelinux.org
  3. Ars Technica: Meet *sshole, the vulnerability that lets hackers SSH into Linux devicesarstechnica.com

Related Q&A

Related services

If you want to try this in your own business

To see how the topics in this article would apply to your own operations, and what it would cost, send us a message through the contact form.