OpenSSH long password bug now exploited

Last Friday I wrote about the OpenSSH long password bug, the one that lets someone into some Alpine Linux servers by typing a password over 256 characters long. At the time, nobody had seen it used in an attack.

That's changed. Attackers are using it now, and the US government added it to its list of exploited flaws yesterday. If you've got Alpine servers, or Alpine containers running SSH, today's the day to check them.

What's new since Friday

It has a number now: CVE-2026-123158. On 9 November, the US Cybersecurity and Infrastructure Security Agency added it to its Known Exploited Vulnerabilities catalog, "based on evidence of active exploitation". US federal agencies have until 12 November to deal with it. Three days.

The security firm GreyNoise runs a network of decoy servers that watch for attacks, and it has put up a page tracking this one. Its timeline shows the fix came out on the morning of 5 November, and working exploit code was on GitHub about four hours later. The first successful break-in on one of its own decoys was in the early hours of 7 November.

GreyNoise describes the bug as "trivial to exploit", and says working exploits are publicly available. When I looked this morning, it had recorded 20 attacks that got in, from six addresses. That's a small number, but these are only the attacks that happened to hit its decoys.

What the attackers did once they were in is the bit that matters. GreyNoise lists running commands, poking at cloud settings, trying to read the password file, and adding their own SSH keys to authorized_keys so they can come back later. That last one is why patching alone isn't enough if you were exposed.

Does it affect you?

Nothing about who's affected has changed. Debian, Ubuntu and Red Hat servers use a different system library and aren't on this path. The risk is Alpine servers, Alpine-based containers with SSH added, and small routers and appliances built on the same library.

The Alpine security advisory sets out the conditions. You're exposed if all of these are true:

sshd runs from Alpine's openssh-server package (built without PAM), or openssh-server-pam with UsePAM no.
Password logins are on, which is the default.
An account has * as its password. On Alpine, root has shipped like that for years.
At least one other account has a real password set.

That last condition is new since Friday. One person setting a password for convenience is enough to open the door.

The advisory also says Alpine's own cloud images (3.18.11 to 3.24.3) ship an alpine user with * as its password and admin rights without a password. Those are the ones to look at first.

What to do today

1. Update OpenSSH. On Friday I couldn't confirm which stable Alpine branches had the fix. Alpine's advisory now lists them all. You want at least:

3.24: openssh 10.3_p1-r2
3.23: 10.2_p1-r1
3.22: 10.0_p1-r11
3.21: 9.9_p2-r1

It also covers the older, unsupported branches back to 3.16. Run apk upgrade -U -a, then check with apk info -v openssh-server.

2. Restart sshd. This is the easy one to miss. Alpine's advisory says upgrading the package doesn't restart the running sshd, so the old one keeps running until you do. On Alpine that's rc-service sshd restart.

3. Turn password logins off anyway. Same advice as Friday, and the advisory agrees: put PasswordAuthentication no in /etc/ssh/sshd_config.d/00-no-passwords.conf. Check your SSH key works first, keep your current session open while you restart, and test a fresh login before you log out.

4. Rebuild containers. If an Alpine image runs sshd, update the base image and redeploy.

Check you haven't already had a visitor

If an affected server has been reachable from the internet since 5 November, have a look before you move on.

Alpine's advisory suggests searching /var/log/messages for Accepted password for lines against accounts that have no password:

grep "Accepted password for" /var/log/messages

Then look at every authorized_keys file, for root, for the alpine user and for anyone else, and make sure you recognise every key in there:

sudo find / -name authorized_keys -path "*/.ssh/*" 2>/dev/null

Look over /etc/hosts and /etc/resolv.conf too, as GreyNoise saw both changed on some of its decoys.

If you find something you can't explain, the advisory says to treat the machine as compromised. I'd agree. Take it off the network, keep a copy for investigation, and rebuild it from a clean image rather than trying to tidy it up.

The bigger point

This went from fix to working exploit in a few hours, and to real attacks in under two days. For anything facing the internet, "next week" is too late.

The team at Dev Partners wrote a good explanation of why the bug happens last week, and it's worth reading if you write code that checks passwords. If the Alpine containers in question were set up by a developer who's since moved on, they take on inherited setups like that too.

For the servers themselves, a health check is the quickest way to find out what's listening, how it's set up and whether anything needs fixing today. I'll tell you in plain English.