TL;DR - Alpine's 5 November security advisory describes an OpenSSH password authentication bypass where an attacker who can reach your SSH port logs in without knowing any password: one connection, works every time, no retries. The bug is CVE-2026-123158, it affects the no-PAM OpenSSH builds that musl distros like Alpine ship, and the fix is in the 3.21.10, 3.22.8, 3.23.8 and 3.24.4 point releases. The catch is that everyone is shouting "patch your Alpine containers" while the advisory explicitly says containers that do not run sshd are not affected. What you need to do: list every Alpine (or other musl) machine that actually runs sshd, upgrade openssh and restart the daemon on those, rebuild any images that carry sshd, and leave your application containers alone unless they run an SSH server.
By The Numbers
| Item | Value |
|---|---|
| CVE | CVE-2026-123158, CVSS 8.1 (Tenable, BSI) |
| Advisory | Alpine Linux, 5 November 2026 |
| What an attacker gets | Login without a password, in one connection, "works every time, needs no retries" (Alpine) |
| The condition | A password field of * on one account plus a $5$ or $6$ hash on another, default PasswordAuthentication yes, no PAM |
| Affected releases | 3.16 through 3.24 and edge, per Alpine's own check |
| Fixed point releases | 3.21.10, 3.22.8, 3.23.8, 3.24.4 (openssh 10.6_p2 class fixes) |
| Not affected | Containers that do not run sshd, systems with PasswordAuthentication no, PAM-enabled builds with UsePAM yes |
| Second-shock advisory | Germany's BSI issued its own warning on 6 November, adding Buildroot, Yocto and OpenWrt to the named platforms |
I read the r/sysadmin thread first, because that is usually where the week's pulse is: "Running Alpine? Patch OpenSSH now", 412 upvotes and climbing, every comment thread underneath it dutifully listing Dockerfiles. Then I read the actual Alpine advisory, and the first thing it says under "Who is not affected" is Docker and other container users that do not run sshd in the container.
Two completely different problems are wearing the same headline. The advisory is about machines that accept SSH logins. The herd read is about container base images, because Alpine is the distro container people know. If you maintain a fleet of application containers that never open port 22, this one skips you entirely. If you have an Alpine VM, a cloud instance, an edge box or a container running sshd, it does not, and the fix is a package upgrade you can run this morning.
Let me walk you through what broke, who it actually hits, and how to check your estate without chasing the wrong machines.
What the bug actually is
OpenSSH on Alpine ships without PAM, which is normal for a distro built around being small. That build lacks a workaround that upstream OpenSSH carries for a password authentication bypass, and the bypass comes down to a single character, as security engineer Gregory Bryant put it in the post ZDNet picked up: *.
The * is what Linux uses in the password field to mean "no password can ever match this account". Root has shipped as root:* in Alpine's base image since roughly 3.16. The bug is a misinterpretation of whether a string presented at login is meant to be a password hash, and when the conditions line up, the check falls open: any password between 256 and 1024 characters succeeds.
Alpine's advisory describes the attacker experience without drama. If you can reach the SSH port, you can log in without knowing any password. One connection, works every time, needs no retries. For an exposed SSH service, that is as bad as authentication failures get, and the German BSI's own advisory notes that proof of concept is public.
Three conditions have to hold together:
- The
openssh-serverpackage built without PAM (oropenssh-server-pamwithUsePAM no). PasswordAuthentication yes, which is the OpenSSH default unless someone changed it.- One account whose password field is
*(root qualifies, so does thealpineuser in the official tiny-cloud images), plus at least one account with a$5$or$6$password hash.
If you run openssh-server-pam with UsePAM yes, or you have password logins switched off, you are out of scope. So is every container that does not run sshd.
The reframe: your app containers are not the target
Here is where the week's coverage and the advisory part company.
The viral read is "my Alpine base images need rebuilding", and it makes intuitive sense: everyone builds from alpine:latest, nobody rebuilds images nobody owns, therefore everybody is exposed. It is a satisfying story. It is also, per the advisory's own not-affected list, mostly wrong. Application containers do not run sshd. They do not listen on port 22. An attacker cannot reach a daemon that is not there.
The machines in scope look more like this:
- Alpine VMs and cloud instances where sshd is how you administer the box.
- The official tiny-cloud images, 3.18.11 through 3.24.3, which Alpine singled out and which do run SSH.
- Containers that deliberately run sshd for container management, jump boxes and test rigs. Yes, some teams do this, and the advisory covers them.
- Any other musl-based system running a no-PAM OpenSSH: Buildroot, Yocto and OpenWrt devices are all named in the BSI's 6 November warning, which means embedded and network gear is part of this story too.
The container angle is not irrelevant, it is just narrower than the headlines. Images that carry sshd need rebuilding so the fixed package flows into new instances, and the BSI's guidance says exactly that: check the images and build pipelines, rebuild affected images, and remember that rebuilding an image does not fix containers already running. Those have to be replaced or upgraded in place.
The fix, in the order that matters
Alpine shipped fixed point releases on 5 November: 3.21.10, 3.22.8, 3.23.8 and 3.24.4, with the edge repository carrying the fixed openssh package too. The upgrade itself is the usual two words:
apk upgrade -U -a
Then the step the advisory puts in bold: upgrading the package alone does not replace the running daemon. You have to restart sshd, or the old, vulnerable process keeps listening exactly where it was.
If you cannot patch right now, the mitigation is to set PasswordAuthentication no in your sshd configuration and restart sshd. Do that in the right order: confirm a key-based login works first, or you will have closed the front door with yourself standing outside it.
For images and pipelines: rebuild from the updated repositories, tag the new images, and roll them. Anything still running the old image keeps running the old daemon until you replace the container.
Why this could be good
This is roughly how a security advisory should read. Alpine's post names the affected releases, gives a "who is not affected" list precise enough to act on, spells out the conditions, provides both a patch path and a mitigation, and credits the reporter (Özgün Kültekin of Wakefield) and the upstream OpenSSH maintainers who shipped 10.6p2 with the fix. The BSI followed within a day with platform coverage Alpine's post does not claim. Nobody had to reverse-engineer their exposure from a CVE number and a blog post. The herd will misread it anyway, but the document itself is a model.
What to do today
- Find the machines that run sshd on a musl base. One command per host:
sshd -Vor check the package, pluscat /etc/os-release. Alpine VMs, cloud instances, tiny-cloud images, embedded Buildroot/Yocto/OpenWrt gear, and any container with sshd in it. - Check the daemon actually listens.
sshdrunning and port 22 open is the exposure. If nothing on the box accepts SSH, cross it off. - Patch and restart.
apk upgrade -U -a, then restart sshd. The restart is the half everyone skips. - Verify the fix landed. Log in with a password after the restart and confirm normal authentication behaviour, and confirm the installed openssh version matches your branch's fixed package.
- Check your auth configuration while you are in there.
PasswordAuthentication nowith key-based access closes this hole permanently, on this bug and the next one. - Rebuild sshd-carrying images, leave the rest. Application containers without sshd are not in scope; images that run sshd get rebuilt from updated repos and rolled.
- For the unpatchable tail, the mitigation stands: disable password logins, restart the daemon, and put a ticket against the upgrade.
Key Takeaways
- Alpine's 5 November advisory covers an OpenSSH password bypass (CVE-2026-123158) where any password of 256 to 1024 characters can succeed, in a single connection.
- Three conditions make it work: a no-PAM OpenSSH build, password authentication left on, and the
*-field-plus-hash account combination that Alpine images ship by default. - Containers that do not run sshd are explicitly not affected, however loud the "patch your Alpine images" chorus gets. Your application containers can wait; your sshd hosts cannot.
- The fix is upgrade plus restart. The advisory bolds the restart for a reason: the package update does not touch the running daemon.
- The blast radius reaches beyond Alpine. BSI named Buildroot, Yocto and OpenWrt on 6 November, so embedded and network devices belong on the same checklist.
FAQ
Are my Docker images affected? Only if they run sshd. Alpine's advisory lists container users that do not run an SSH server as not affected. Rebuild images that do carry sshd, and leave plain application images to their normal rebuild cycle.
How do I check a machine?
Confirm it runs a musl-based distro, that openssh is installed without PAM, that PasswordAuthentication is on, and that sshd is listening. Then apk upgrade -U -a and restart sshd. Ten minutes per host.
Do I have to restart sshd after patching? Yes. The advisory calls it out specifically: upgrading the package does not replace the running daemon, so the vulnerable process keeps serving logins until you restart it.
I cannot upgrade right now. What stops the attack?
Set PasswordAuthentication no and restart sshd, but only after confirming key-based login works, or you risk locking yourself out. The restart is what applies either change.
Is this an Alpine-specific bug? It is an OpenSSH-without-PAM problem, and Alpine is the biggest platform that ships that configuration. The BSI's advisory also names Buildroot, Yocto and OpenWrt, so other musl systems are in scope regardless of the distro name on the front.
Is there exploitation in the wild? Alpine's advisory and the BSI warning both describe the vulnerability and the fix, and the BSI notes a public proof of concept. The window between public PoC and scanning for this class of bug has been measured in days all year, which is why the advisory's tone is "now", not "next maintenance window".
My Take
The most interesting thing about this week's Alpine story is not the bug. It is the distance between the thread title and the advisory, and how confidently the internet marched towards the wrong machines because the title was catchier.
That gap is where real exposure hides in both directions. Hundreds of teams will spend today rebuilding application containers that were never vulnerable, while the VM someone spun up for a migration in March sits on an open sshd with password logins on, invisible in the noise. The discipline worth taking from this is smaller than the headline: know which of your machines accept SSH logins, keep the package current, and treat "who actually runs this daemon" as the first question of any patch, not the last.
The single-character version of this bug is the part I keep coming back to. A * in a password field has meant "no password here" for decades, and the failure was one misread string away from a bypass. Your estate has its own versions of that assumption sitting in configs nobody has opened since the box was built.
Mathew Clark Founder, SecureInSeconds Currently: working down a list of machines that accept SSH, which is a list nobody enjoys making Drafted with AI assistance - read, verified, and fixed by a human.
Further Reading
- Alpine Linux: Security advisory - openssh-server password authentication bypass - the source: conditions, affected releases, fix versions and the restart warning
- Tenable plugin 478605: Alpine openssh security update - CVE-2026-123158 scoring and the any-password-of-256-to-1024-characters detail
- ZDNet: Alpine Linux and OpenSSH patch flaw that's as bad as it can get - the single-character
*explanation and the tiny-cloud image range - r/sysadmin: Running Alpine? Patch OpenSSH now - the week's loudest thread, and the container framing this piece pushes back on
- PHP2Shell is coming: your patch window is 15 minutes - patch speed as an operations problem
- Linux kernel KEV trio: four public root exploits - the same checklist on a different platform
- Your router security risk and how to fix it in 10 minutes - the consumer-sized version of "who is listening on this box"
