OpenSSH issues an emergency patch for a flaw that bypasses SSH login

There are vulnerabilities that can be explained in one sentence and, even so, are hard to believe. This is one of them: on certain Alpine Linux servers running the standard openssh-server package, an attacker can log in to accounts that have no password —for example, accounts configured only with an SSH key— by sending a password between 257 and 1,024 bytes long. Nothing more. No complex exploit, no chain of cascading failures.

OpenSSH has classified the problem as critical and has released version 10.6p2 to close it. Alpine, for its part, has already distributed patched packages. The conditions for exploiting it, however, are not trivial: network access to the server is required, as is knowing the name of a valid account. But when they are met, the flaw turns a reasonable defense (disabling password access and relying only on keys) into an unexpected entry point.

Why it matters more than it seems

SSH is the service gateway for almost any small or medium-sized infrastructure: web servers, containers, appliances, virtualization equipment, backups. In an SMB there is usually no dedicated team reviewing every security advisory for every component. And that is precisely the ground where this type of flaw does damage: not because the attack is sophisticated, but because it goes unnoticed until someone tries it.

Alpine Linux also carries particular weight in container and lightweight system environments. Many companies do not know they are using it: it is inside a Docker image, in a router, in a NAS or in a service managed by a provider. That layer of invisibility is what turns a one-off flaw into a real inventory risk.

It is worth framing this within a trend we have already been observing: flaws in foundational components accumulate, and the window between the publication of the patch and its application remains the weak link. We saw it with the WordPress update and the attack window it opens, and we are seeing it with the Linux root exploits that OpenAI's AI has brought to light. The pattern repeats: the problem is not the patch, it is the time it takes to arrive.

What an IT team should do this week

There is no need to panic, but there is a need to act in an orderly way. These are the recommendations we give our clients:

1. Locate every OpenSSH you depend on. Not just physical servers: check container images, appliances, network equipment and any managed service where your provider runs SSH. Ask explicitly about the version.
2. Check the version. If you run Alpine with openssh-server, verify whether you already have Alpine's patched packages or whether you can move to OpenSSH 10.6p2. Updating is the only real mitigation.
3. Prioritize what is exposed to the Internet. An SSH accessible from outside is the high-risk scenario. Those on the internal network can wait for the maintenance window, but not indefinitely.
4. Review the authentication logs. Look for failed or successful attempts with abnormally long password strings. If you detect anything strange on an account without a password, treat it as a compromise and rotate keys.
5. Strengthen access control. Limit SSH to known IP addresses, use a VPN or bastion and enable multi-factor authentication wherever possible. It does not replace the patch, but it reduces the surface while you apply it.

A lesson in hygiene, not just in patches

This flaw is a reminder of something that is sometimes forgotten: passwordless accounts are not immune by definition. Key-based authentication is a good practice, but it depends on the code that evaluates it behaving as we expect. When it does not, the absence of a password becomes an open door if the attacker finds a way to bypass the check.

For an SMB, the practical conclusion is twofold. First, maintain an up-to-date inventory of components, including those that come inside containers and appliances. Second, have a clear process for applying critical patches, with owners and deadlines. Without that, every advisory like this becomes a race against the clock that is lost by default.

If your team does not have visibility into which versions of OpenSSH are running in your infrastructure, that is the problem to solve before the patch itself. At ForgeNEX we help SMBs set up that inventory and define a realistic update cycle, because security is not played out in a single advisory: it is played out in consistency.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.