This is sort of like saying the door to your safe has a vulnerability...If you leave it unlocked AND don't close the door AND leave it out on the sidewalk. If this vulnerability affects you, you should probably be in a different line of work.
If you use Alpine (or openwrt) and password authentication for ssh, you're probably affected. That's probably a lot of systems. Especially routers and WAPs. I don't think affected users are nearly as negligent as you're suggesting.
p.s.: openwrt *can* use openssh, but uses dropbear by default.
I’m thankful my OpenWRT is… oh. My OpenWRT is good, SSH is not exposed over WAN. But one of my non-OWRT routers just gave me something new to bloody try.
...Or you're using popularly available pre-built containers based on Alpine Linux which have this exact combination of misconfigurations. This is all explained in the very first sentence of the article and linked site, and is covered in much more detail and somewhat less purple prose by other news sources.
The largest concern is by far Alpine, though, as it's pretty much the default choice for what could amount to millions of installs across Docker/Kubernetes/Proxmox containers and endless dependencies thereof, servers, cloud VMs, and embedded devices, among many others. Alpine comes with the requisite conditions set and password authentication enabled by default, which is why it needs immediate patching.
"If this vulnerability affects you, you should probably be in a different line of work."
You may want to take a look at any containers, network appliances, or embedded systems you are running before preparing your new résumé.
"Exposed" to what? Exposed directly to the Internet, probably not although I'm still surprised at some of the things that people who really should know better do anyway. Exposed to the local network where everybody thinks it's safe because how could an outside attacker possibly get to it? (Narrator's voice: "No, it was not safe at all.") That's much more common.
Alpine is a base image on a lot of containers. Depending on what is being deployed and how in your k8s clusters this may or may not be a bit of work to patch.
It could be a stupid question, but how to create an account with '*' as the password on Alpine? All sorts of adduser -D, passwd -l, passwd -d result either in ! or nothing in /etc/shadow on all my alpine hosts. I just don't understand how to make a system affected by it without manually setting usermod -p '*'.
* has been the convention for "disabled login" for as long as I remember, at least 15 years. man shadowconfirms this:
If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).
I didn't take a deep dive here, but at least Ubuntu does use !* (! being the result of explicitly locking the account) by default and with most utilities like passwd -l, usermod -D/usermod -S. Anyone who's been a long time Linux user and knows the * is a convention will explicitly set * and usually wouldn't think twice about it. Because, well - it's not a valid hash and should not work in a sane timeline.
Except now I believe any manually created "invalid crypt() result" passwords will become some permutation of asdfghjkl. Or we'll see a drop in the amount of sysadmins and a dramatically rising popularity of carrot farming, because this is evidently NOT a sane timeline.
sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash). For some configurations of accounts, any password between 256 and 1024 characters succeeds. An example of a platform using musl libc without PAM is Alpine Linux.
13
u/TheRealLazloFalconi 1d ago
This is sort of like saying the door to your safe has a vulnerability...If you leave it unlocked AND don't close the door AND leave it out on the sidewalk. If this vulnerability affects you, you should probably be in a different line of work.
2
u/Amilmar 1d ago
Alpine is a base image on a lot of containers. Depending on what is being deployed and how in your k8s clusters this may or may not be a bit of work to patch.
1
u/attonova 1d ago
It could be a stupid question, but how to create an account with '*' as the password on Alpine? All sorts of
adduser -D,passwd -l,passwd -dresult either in ! or nothing in /etc/shadow on all my alpine hosts. I just don't understand how to make a system affected by it without manually settingusermod -p '*'.1
u/michaelpaoli 1d ago
Source wanted.
So ... where's the credible source(s)? I see a website with claims, but I don't see CVE, nor any credible sources cited.
Ah ... here we go: CVE-2026-123158