Title
Threat Notice: The OpenSSH Bug That Lets a Long Password Walk Right In
The Wrong Password That Works
We've all been taught that longer passwords are safer. So here's a twist nobody saw coming: on certain Linux servers, typing a really long password, any password at all, could let a stranger log straight in.
On November 5, 2026, the OpenSSH project released an emergency fix for exactly that. Security researchers have nicknamed the bug "*sshole." It's rated critical, it affects a popular, lightweight Linux system called Alpine Linux, and it can hand an attacker full control of a machine.
Let's break down what happened, who needs to worry, and what to do about it, without the jargon.
So, What Actually Went Wrong?
OpenSSH is the software that lets IT teams log in to servers remotely. Think of it as the front door to a computer. It runs on millions of machines worldwide.
Here's the simple version of the bug. Some accounts on a server aren't supposed to accept passwords at all. Instead of a password, the system stores a single placeholder symbol (an asterisk, "*") that basically means "no password login allowed here."
The problem is that on Alpine Linux, the part of the system that checks passwords also returns that same asterisk when something goes wrong. Send it a password longer than 256 characters, and it gives up and spits out "*" as an error. OpenSSH then compares that error with the stored placeholder, sees a match, and lets the person in.
In other words, an attacker who can reach the server's login port can type any password between 257 and 1,024 characters long, and walk through a door that was supposed to be locked. No special hacking tools required. A password of 300 letter A's would do the job. Researchers say the underlying issue has been quietly sitting there since 2016.
From Front Door to Master Key
Alpine Linux's official cloud images come with a built-in user called "alpine." That account has no password, and it's allowed to run commands with full administrator ("root") powers without being asked for a password.
Put those together and you get a nightmare scenario. On an affected cloud server, an attacker could log in as "alpine" using a junk password, then instantly promote themselves to root. That means total control: reading data, installing malware, creating hidden accounts, or using the server as a launchpad to attack the rest of your network.
There's one condition for the attack to work: at least one other account on the machine needs to have a normal password. On real-world servers, that's often the case.
Should You Be Worried? A Quick Gut Check
This one is narrower than it sounds, which is good news. You're likely exposed only if all of these are true:
The server runs Alpine Linux or another Linux system built on a library called musl. Others named by researchers include OpenWrt (common on routers), Buildroot and Yocto (common on embedded devices).
The SSH login service uses Alpine's standard setup, which skips an extra security layer called PAM.
Password logins are switched on, which is Alpine's default.
The server's login port can be reached by an attacker, for example from the internet.
You're not affected if your servers run mainstream Linux systems like Ubuntu, Debian or Red Hat, if they use PAM, or if password logins are turned off.
Why does this matter beyond tech companies? Alpine is a favorite for cloud servers and containers because it's small and fast. Many modern apps, including the online tools businesses rely on every day, run on it behind the scenes. You may be using it without knowing.
The Good News (Yes, There Is Some)
No attacks using this flaw had been reported when it was disclosed, and fixes are already out. OpenSSH released version 10.6p2, and Alpine Linux published patched packages for every release from 3.16 onward.
The catch is that the clock is now ticking. Once a bug like this is public, and this one is very easy to exploit, attackers start scanning the internet for servers that haven't been updated. The window between "disclosed" and "exploited" is often measured in days.
Four Moves to Make Before Attackers Do
You don't need to understand every detail. You just need to make sure someone on your team (or your IT partner) does these four things:
Patch and restart. Update the OpenSSH server package on every Alpine machine, then restart the SSH service. This step trips people up: updating alone isn't enough, because the old version keeps running until it's restarted.
Can't patch today? Turn off password logins. Switching off password-based SSH logins blocks this attack completely. Most servers should use secure keys instead of passwords anyway.
Close the door to strangers. Limit who can even reach the SSH login port, so only trusted locations and networks can connect. A door nobody can reach can't be picked.
Check old images and containers. Rebuild any server images or containers that bundle an older version, and give extra attention to anything running Alpine older than 3.16, which won't receive a fix.
Patching Locks the Door. It Doesn't Check Who's Already Inside.
This is the part most people skip. A patch stops new break-ins, but it does nothing about someone who may have already slipped in.
So after patching, look back. Your server's login records show every successful sign-in. A successful password login to an account that has no password, such as "alpine," "root" or a key-only account, is a major red flag. Researchers advise treating any machine with that kind of entry as compromised.
Keep watching after that, too. Attackers who get in usually try to stay in, by creating new accounts, planting backdoors or quietly moving to other systems. Spotting that behavior early is what stops a single break-in from becoming a full-blown breach.
The Bigger Lesson: Remote Access Is Prime Real Estate
This bug hid in plain sight for about a decade, inside software trusted by millions. That's the reality of modern security: you can't assume yesterday's safe setup is still safe today.
Remote access tools like SSH are a favorite target because they lead straight into your systems. That's where PureStack comes in. We keep track of threats like this so you don't have to, check your systems for exposure, patch and harden them, and watch around the clock for the warning signs that someone has already gotten in.
Not sure if this affects you? Book a free security check with PureStack and we'll tell you where you stand.
