are you affected?
- is your sshd running on musl? (alpine, openwrt, buildroot, yocto)
- is it not using pam? alpine’s openssh-server doesn’t by default, or maybe you set UsePAM no
- are password logins still on? they are by default
- is there an account with just * as its password? key-only users, ldap users, root on alpine
- and some other account with a real password?
- then that * account takes any password between 257 and 1024 characters
on alpine’s official aws and azure images that’s the default alpine user, and it has passwordless doas. so it’s root
on debian, ubuntu, fedora or anything else with glibc? going through pam? dropbear? openbsd? you’re fine
I’m no cybersecurity expert, but from what I’ve heard from those who are, this is the new normal as anyone who formerly had no chance due to being a “script kiddie” can now just prompt an AI* to eventually find a vulnerability.
* oversimplification redacted
Yep, those new fangled slop-kitties. The worst part is that there brute force hacking is being subsidized by people 401ks.
The irony - of course - is that their 401k money goes right into hacking those same people’s 401ks.
… but at least we can brainrot an entire generation with glass fruit slices and put artists out of work?
Now if you’ll excuse me, I have to go convince someone that the TikTok deepfakes they’re watching aren’t real and that cops don’t really employ nanny-boo-boos to unsettle criminals during interrogations. No, I’m not joking.
It’s not quite as simple as that. The author in this case followed a pretty specific trail to find the bug.
Where AI helped was as the last step. They already knew what the bug would do and where to look, but actually looking through the source code for all the possible musl implementations out there would have taken a lot of time.
So they brute-forced it instead and asked AI to spin up actual running instances of all those implementations and simply tried the bug against each of them, rather than looking at all the code.
Fair enough, but the overall idea stands:
The bar has been significantly lowered for what it takes to hack.
That’s because it turns out there are tons of vulnerabilities out there introduced by very lazy and/or dumb code.
It isn’t that AI has lowered the bar for hacking, it’s that it’s showing us just how much bad code is out there. The bar was already on the ground, we just didn’t know it.
After all is said and done AI will actually end up raising the bar for security everywhere.
Unfortunately we have a lot of legacy crap to clean first.
You’re doing mental gymnastics to argue with me. Let’s try what I said worded differently in a way that hopefully helps you realize we agree:
It is now easier to hack.
The way it works is that finding vulnerabilities required a lot of technical understanding and mental effort. A software could have a glaring hole in it for years without anyone finding out simply due to nobody really looking. AI just gives you the ability to do rudimentary exploit analysis around the clock without having to spend your own time. This is a wake up call to anyone making software in sloppy fashion.
But it isn’t quite as easy as saying “AI hack into this service”, if the person doing the hacking is using the same model as the person who made the service, and that person already asked the AI to do that and fixed the resulting exploit prior to release.
Even projects that use AI in a limited fashion to code or even not at all, often use AI to at least do some red team stuff prior to release.
I don’t really foresee any way this doesn’t even out eventually.
I’m assuming this is only if you allow password authentication? If you’re only allowing certificate based auth you should be safe, right?
Correct, password authentication must be enabled on the SSH daemon side of things to be vulnerable. The user account being logged into, on the other hand, can’t have a password set. But overall, PW auth must be on. The website OP linked is exceedingly bad at explaining the actual problem, see Alpine’s announcement for better info.
https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Yep
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
The “are you affected?” section directly contradicts this. It outright states you must have password authentication enabled. Otherwise, SSH never gives you a chance to even attempt a password.
Bottom of the page says what to do and gives 2 options to mitigate:
# update. openssh 10.6p2 fixes it. $ apk upgrade openssh # can't update yet? turn password logins off. $ echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf $ rc-service sshd restartSo if you disable password auth and only allow key auth, then you are unaffected (safe).
The introis a bit confusing but it means that if you have password auth on - then even if your regular ssh login requires a key, you are not safe.
Ah. Thanks for the correction. The intro + where I originally learned this from made me overreact a bit, it seems.
Certificate or key based auth is unaffected
NO! Exactly the opposite, that is the problem. Key-only is a prerequisite for this.Edit: see also, the first thing that pops up under the link.I was wrong, see below.
This isn’t nearly as bad as I thought it was. Also the author is very reliant on AI to the point where they didn’t think about what if someone wipes the logs.
Any effected devices should be wiped and redeployed
OP I know you’re trying to do good, but please try to understand the vulnerability before spreading FUD
Yeah fair, sorry about that. The intro + where I originally learned this from made me overreact a bit, it seems.
That website is atrocious. It’s the web design equivalent of shoving five kilograms of sugar and whipped cream in a cup of coffee.
“Cyber” ppl love to do this. This is basically their resume I guess? They have to sensationalize absolutely everything they can (not that this isn’t an important bug, but this could have been a 1-2 page white paper imo (like many of them))
Most containers don’t run ssh right?
Unless it’s explicitly installed no. The default Alpine image doesn’t come with OpenSSH.
Why would a local server even have open internet access though?
This alerts feel more relevant for public facing servers.
The only container i have that has a reachable SSH port is forgejo, and even then it’s only local traffic and i’d have to check if it even uses alpine. All others also don’t have SSH enabled.
The vulnerability doesn’t seem too bad tbh.
I mean, anybody who’s still using password login for SSH is kind of asking for it.
Why
I use alpine with an ssh port exposed to the internet so I can connect to it. This doesn’t seem to be an issue if you configured your settings to be secure.
Never use just default settings.
Are your containers running Alpine?
Most containers (99%) I have ever used were using Alpine because it’s small and fun. lol.
And 99.9% won’t have either ssh at all, or the port open, or password auth enabled.
This is a nothing burger
People use * as an account password, or sysadmins allow that? I’d never allow that on any system or service of mine. No surprise, like most of these LLM discovered issues in the media lately, it hasn’t come up before. 💯 Good they’re getting fixed, but nothing so far has really been that urgent to fix for me.
No,
\*is being put as a hash of a password, originally precisely because that would mean no actual hash (over any input) ever matches it.Ah got it, so is that a hack to prevent a specific user from logging in rather than something like:
Match User <username> PasswordAuthentication no
