The editorial emphasizes that the bug lives in Alpine's PAM wiring, not in Portable OpenSSH itself, so the same sshd binary is safe on Debian but lethal on Alpine. This matters operationally because CVE scanners keyed on upstream OpenSSH version strings will report vulnerable hosts as clean, leaving responders blind.
Alpine's own advisory locates the defect in the distro's openssh-server package wiring to PAM, not upstream OpenSSH code. By publishing under their own advisory channel rather than coordinating a CVE against Portable OpenSSH, they implicitly frame this as a packaging/integration bug Alpine owns.
The editorial argues authentication bypasses in sshd are the worst class of bug in the worst place in the stack — no WAF rule or clever workaround helps, because one TCP connection equals a shell. It explicitly frames the only acceptable response time as 'before the next coffee.'
By submitting the Alpine advisory directly to Hacker News and driving it to 361 points, pantalaimon is signal-boosting this as a top-of-queue operational emergency for the sysadmin community. The framing of the submission treats the advisory itself as the news, consistent with urgent-patch posture.
The editorial pushes back on the comforting narrative that 'Alpine containers use keys by default, so this is a non-event.' It argues the realistic exposed surface includes debug images, hastily-built one-off containers, bastion hosts, and the long tail of ad-hoc `apk add openssh` installs operators have long since forgotten about.
Alpine Linux published a security advisory on November 5, 2026 disclosing that the `openssh-server` package in affected Alpine releases can accept password authentication without actually validating the password. In plain English: on a vulnerable host with password auth enabled, an attacker who knows (or guesses) a valid username can log in by typing anything at the prompt — or nothing at all.
The bug is not in upstream OpenSSH. It's in how Alpine's build wires OpenSSH into the system's PAM stack, which means the same `sshd` binary is safe on Debian and lethal on Alpine. The advisory points at the distro-specific auth plumbing — the glue between `sshd`, PAM, and the password database — rather than at Portable OpenSSH itself. That distinction matters for anyone triaging: your CVE scanners keyed on upstream version strings will happily tell you everything is fine.
The practical blast radius is Alpine systems where `PasswordAuthentication yes` is set in `sshd_config` and sshd is reachable from somewhere an attacker can speak TCP to it. That is a smaller set than "all Alpine boxes" — hardened container images disable password auth by default and lean on keys — but it is a much larger set than operators tend to admit once you include debug images, hastily-built one-off containers, bastion hosts, and the long tail of `apk add openssh` someone ran six months ago and forgot.
Authentication bypasses in sshd are the worst class of bug in the worst place in the stack. There is no clever mitigation, no WAF rule, no "it's only exploitable under specific conditions." If a vulnerable sshd is listening and password auth is on, you are one TCP connection away from a shell. The only acceptable response time to a pre-auth bypass in OpenSSH is "before the next coffee."
The more interesting question is how this class of bug keeps shipping. OpenSSH itself has one of the most paranoid development cultures in open source — privilege separation, memory-safe rewrites of critical paths, decades of audits. And yet distros keep finding creative new ways to break it on the integration seam. In 2024 the `xz-utils` backdoor rode in through a build-system compromise that targeted sshd via a library it didn't even link against directly. In 2026 Alpine ships a PAM wiring that forgets to check the password. The pattern is consistent: the vulnerability is rarely in the code everyone is watching; it's in the connective tissue nobody owns.
Alpine's role here deserves a fair reading. The distro is the default base image for a huge chunk of the container ecosystem precisely because it strips things down — musl instead of glibc, BusyBox userland, minimal PAM. That minimalism is a feature right up until the moment it means the auth path is subtly different from every reference implementation, and a subtle difference in an auth path is exactly how you ship a bypass. The community reaction on Hacker News (361 points as of this writing) split predictably: half of the thread is "this is why you disable password auth," and the other half is "this is why distro-specific auth stacks are a liability." Both are correct.
For security teams, the advisory is also a reminder that software bills of materials and vulnerability feeds keyed on upstream package names will miss this entirely. The vulnerable artifact is `openssh-server` *as packaged by Alpine*, not OpenSSH-the-upstream-project. If your SBOM pipeline normalizes Alpine packages to their upstream CPE, you will get a clean report for a box that is actively on fire.
First, the obvious: `apk update && apk upgrade openssh-server` on every Alpine host and rebuild every Alpine-based container image that includes openssh-server. If you're running Alpine in Kubernetes with sshd baked into a debug sidecar, this includes you. If you have a "we don't run Alpine in production" policy, this still probably includes you — check your CI runners, your jumpboxes, and anything a developer spun up to "just quickly debug something."
Second, turn off password authentication. If `PasswordAuthentication no` and `ChallengeResponseAuthentication no` are set in your `sshd_config`, this bug cannot be exploited against you even on an unpatched host. Key-based auth should have been the default a decade ago; use this as the forcing function to finally rip out the password paths you kept around "just in case." Combine with `PermitRootLogin prohibit-password` and you've eliminated an entire category of future advisories in one config change.
Third, audit. `last`, `lastb`, and the auth log on every Alpine host that had password auth enabled. Look for successful logins from unexpected source IPs, logins at odd hours, logins immediately followed by a sudo. The advisory doesn't yet have a confirmed exploitation timeline in the wild, but pre-auth sshd bugs don't stay unexploited for long, and the delta between "advisory published" and "metasploit module lands" is usually measured in hours.
The deeper lesson is one the container ecosystem keeps refusing to internalize: when you pick a base image, you are also picking that distro's auth stack, its PAM configuration, its CA bundle, and every integration decision its maintainers make at 2am on a Saturday. Alpine is a fine choice. So is Debian slim, so is Chainguard, so is distroless. But "minimal" is not the same as "safe," and the security properties of your production fleet are determined by whichever Dockerfile line you last edited, not by the upstream project's reputation. Patch this one today, then spend next week auditing which of your base images still ship sshd at all. Most of them shouldn't.
IMO this is where languages like Rust shine. The design patterns built into the language for handling errors (Result) - force you to handle errors / function results with sentinels, null pointers, or errnos are so much more error prone than handling a Result<T,E> using a match statement.c
Discussion from a few hours ago:https://news.ycombinator.com/item?id=50377221
Given Alpine’s broad use in the Docker ecosystem, this is going to hit a lot of folks, I think.
I run Alpine on hardware. I was not effected by this as while I do use ssh keys, there are no user accounts without passwords on my server.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
musl’s crypt() returns the string * as an error indicator when the key is over 256 bytes long. * is also exactly what the stored field contains for every account with no password, so the “hash” matches and the login succeeds.Does anyone know why musl does this? Are they the only C library that behav