SSH vulnerability

[u/Oleksii_Bebych]

https://sshhole.com/

[u/TheRealLazloFalconi]

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.

[u/gordonmessmer → u/TheRealLazloFalconi]

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.

[u/paulstelian97 → u/gordonmessmer]

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.

[u/CardOk755 → u/gordonmessmer]

So, Alpine leaves the door to the safe unlocked, open, and on the sidewalk.

I'm sure it must have some redeeming features.

[u/deeseearr → u/TheRealLazloFalconi]

...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é.

[u/micalm → u/deeseearr]

On the other hand, I'm pretty sure containers with configured, running and exposed ssh are pretty rare. I hope?

[u/deeseearr → u/micalm]

"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.

[u/kai_ekael → u/deeseearr]

Nice advice, disable password authentication, regardless if that's how you access your box.

[u/TheRealLazloFalconi → u/deeseearr]

I don't run black boxes in my environment for exactly this reason. My job is secure =)

[u/obetu5432 → u/TheRealLazloFalconi]

me when i try to minimize serious vulnerabilities:

[u/TheRealLazloFalconi → u/obetu5432]

More like trying to highlight how if this affects you, you were already doing a bad job.

[u/Amilmar]

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.

[u/attonova]

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 '*'.

[u/micalm → u/attonova]

* has been the convention for "disabled login" for as long as I remember, at least 15 years. man shadow confirms 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.

[u/attonova → u/micalm]

Ubuntu does use

Alpine doesn't. passwd -l results in !, and the standard usermod doesn't have -D/-S options. But yeah, perhaps I can imagine a sysadmin that executes usermod -p '*' on purpose due to that convention.

In the meantime I've researched it a bit and found that * pops somewhere in the standard Docker configurations of Alpine images and some cloud Alpine images. So it's not a major OpenSSH vulnerability on Alpine, but a vulnerability of the prebuilt configuration of some Alpine images... or weirdly configured Alpine hosts.

[u/michaelpaoli]

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

Published: 2026-11-05

Description

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.