Enterprise IT News

Enterprise IT News Alert: One Asterisk Unlocks Alpine SSH

By Nattapong Sukkasem · Published 2026-11-07 · Updated 2026-11-07.

TL;DR — OpenSSH shipped an emergency release, 10.6p2, on 5 November after researchers found that an attacker who sends a deliberately over-long password can log in to accounts that have no password at all. The bug bites only on Linux systems built against the musl C library with PAM disabled, which in practice means Alpine Linux and some embedded builds. Alpine has patched every branch from 3.16 up. The reason this is enterprise IT news and not a footnote is that neither component involved is behaving incorrectly: the failure lives entirely in the space between them.

Two pieces of software, each doing exactly what its own documentation says, can still add up to an unauthenticated login. That is the shape of the week's most instructive enterprise IT news, and it is worth understanding even if you do not run a single Alpine host. On 5 November the OpenSSH project published 10.6p2 and described it, in unusually direct language, as a critical security workaround. The project also said something administrators rarely hear from an upstream: the root cause is not in sshd.

Enterprise IT news: a boot console showing the OpenBSD Secure Shell server starting, the daemon affected by CVE-2026-123158 on musl-based Linux systems such as Alpine Linux — The OpenSSH daemon announcing itself at boot. On a musl-linked build with PAM disabled, this line marks the moment the flaw becomes reachable from the network.

What shipped on 5 November, and where

The flaw is tracked as CVE-2026-123158. MITRE issued a CVSS 3.1 score of 8.1 with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, and classifies it as CWE-394, “Unexpected Status Code or Return Value” — a category name that is, for once, a precise summary of the problem. Note that the published numbers do not agree with the published words: OpenSSH calls the issue critical, MITRE's score lands in the high band, and at least one vendor rates it critical on its own assessment. Treat the label as noise and the mechanism as the signal.

Upstream, the fix is OpenSSH 10.6p2. Alpine Linux published patched packages the same day across every branch it checked, from 3.16 through edge, including 3.21 despite that branch having reached end of support on 1 November. Fixed point releases are 3.21.10, 3.22.8, 3.23.8 and 3.24.4.

How one asterisk became a valid password

Without PAM, sshd hashes the password you typed itself, using the system crypt() function, and compares the result against the field stored in /etc/shadow. For an account with no password, that stored field on Alpine is a single character: *.

musl's crypt() refuses keys longer than 256 bytes — a deliberate denial-of-service guard added in 2012. Rather than returning a null pointer, it returns a short string that cannot match any real hash. The string it chose is *.

Step	What happens
Connect	One SSH session, naming any local account whose stored password field is a bare `*`
Send	A password of 257 to 1,024 bytes, above musl's ceiling and below the limit sshd itself enforces
Salt	The stored `*` is too short to carry a salt, so sshd borrows one from another account that has a real hash
Hash	`crypt()` rejects the over-length key and returns its error indicator: the string `*`
Compare	sshd compares the returned `` against the stored ``. They are identical
Admit	Authentication succeeds, with that account's own privileges

The salt-borrowing step in the middle is not an oversight either. It arrived in July 2016 as the remedy for CVE-2016-6210, a username-enumeration bug: by hashing against a borrowed salt, sshd made failed logins for non-existent users take realistic time. It closed a timing channel and, a decade later, supplied the path that makes this comparison happen at all.

Enterprise IT news: a real OpenSSH command line session showing password authentication to a remote root account, the exact authentication flow abused by CVE-2026-123158 on Alpine Linux servers — The flow the bug abuses, in an ordinary OpenSSH session: a password prompt, then a shell. Nothing about the exchange looks unusual from either end.

Why glibc hosts are fine and musl hosts are not

Damien Miller of the OpenSSH project has been explicit that the problem “does not exist on non-Linux systems, Linux/glibc systems and Linux systems that use PAM for password authentication”. Dropbear, the small SSH server that OpenWrt ships by default, is unaffected. The same OpenSSH source, compiled twice, is safe in one build and exploitable in the other.

That is the fact this enterprise IT news story turns on, because it breaks a mental model almost every asset inventory is built on. Most teams track server infrastructure as a list of programs and their versions. This bug is invisible at that level of detail. Your inventory needs a second column: which C library each of those programs was linked against, and whether the build passed authentication to PAM or kept it in-process.

There is also no zero-day vulnerability at either end of this chain. musl's 256-byte limit was documented in 2012. Its decision to return an unmatchable string instead of a null pointer was documented three weeks earlier. The OpenSSH salt-borrowing was a published security fix in 2016. Every individual decision was reviewed, reasonable and public. The vulnerability was composed, not introduced, and then nobody looked at the composition for ten years.

Alpine Linux builds openssh-server without PAM and enables password logins by default, which is why it is the distribution at the centre of this advisory.

Four conditions, and most Alpine hosts meet three by default

Exploitation needs all four of the following. Alpine supplies the first two out of the box, and the third is extremely common.

sshd built without PAM, or built with PAM and run with UsePAM no.
PasswordAuthentication yes, which is the upstream default.
At least one account whose password field is *. On Alpine that has included root since roughly 3.16, along with key-only users and accounts supplied through a directory service.
At least one other local account carrying a real $5$ or $6$ hash, to donate the salt. As the Alpine advisory puts it: “One user with a password is enough: it makes every account without one reachable.”

This is where cloud security stops being abstract. Alpine is chosen as a base image precisely because it is small, and Alpine tiny-cloud images from 3.18.11 to 3.24.3 ship a default alpine user with an empty password field and passwordless doas. Those images are safe at first boot. They become exploitable the moment anyone sets a password on any account. The exposure is not a property of the image; it is a property of what an operator does to it afterwards.

Exploitation arrived within hours

The threat intelligence firm Previdian reported the first exploitation attempt against its honeypot less than nine hours after the CVE record was published, and says it confirmed root access on an Alpine Linux host. Volumes were tiny: eight attempts, from a single address geolocated to Japan. After landing, the intruder ran id, uname and hostname through non-interactive sessions, and nothing further has been reported.

Carry the hedges. No compromise of a production system has been published anywhere. Reporting from 5 and 6 November disagrees on whether exploitation had been seen at all, which looks like a timing difference rather than an error. Sources also disagree on whether both $5$ and $6$ hashes trigger the behaviour or only $6$ , and on whether a default Alpine install leaves root directly reachable, since PermitRootLogin prohibit-password blocks that path unless an operator changed it.

Eight packets is the detail worth keeping. A DDoS attack is an argument about capacity, and capacity planning is a discipline with budgets, dashboards and on-call rotations behind it. Nothing in a capacity model protects you against an authentication decision that is wrong by one byte, and nothing in your traffic graphs will show you eight successful logins.

Enterprise IT news: a DNS server performance benchmark comparing public resolvers, the kind of measurement that helps administrators confirm which resolver their hardened Linux hosts are actually using — A **DNS server performance** benchmark. Knowing which resolver a hardened host actually uses is part of knowing what that host can reach.

What to do this weekend

Patch, then restart the daemon. On Alpine, apk upgrade -U -a followed by rc-service sshd restart. Upgrading the package does not replace the sshd already running.
If you cannot patch now, turn off password logins. Set PasswordAuthentication no, including inside any Match blocks, keep your current session open while you verify key access, then confirm with sshd -T | grep -i passwordauthentication.
Read the shadow file before you read the logs. Any account with a bare * is in scope; an account locked with ! is not. That distinction decides your blast radius.
Hunt for successful logins, not failures. Search /var/log/messages for Accepted password for against accounts that have no password. Alpine's guidance is blunt: if you cannot rule out a login, treat the machine as compromised.
Extend the sweep past your servers. musl is the libc of small Linux: OpenWrt, Buildroot and Yocto builds may be affected wherever someone installed the OpenSSH server in place of Dropbear. Confirm reachability of each one, and use a network diagnostic tool to establish what those devices can resolve and reach outbound.
Write down the libc column. The IT security task this advisory actually sets is producing a list of every musl-linked image in your registry and every appliance built on one. Produce it this week while the question is concrete, because the next bug in this class will arrive without a convenient distribution name attached.

Enterprise IT news: a network latency comparison across public DNS resolvers, useful for verifying the resolver configuration of embedded and container hosts after the OpenSSH musl password bypass — Resolver **network latency** measured side by side. Embedded devices frequently inherit a resolver nobody chose deliberately.

The seam is the story

Follow this bug outward and it stops being about Alpine. musl is what runs on the appliance in the comms cupboard, the access point, the branch router. Those devices increasingly terminate DNS over HTTPS on behalf of everything behind them, which means a root shell on one of them is a root shell on the machine that answers every name query on that network, and that answers them inside an encrypted session your own resolver never sees. If you have ever changed the DNS settings on your router, you have administered exactly this class of device.

The durable lesson of this enterprise IT news is about ownership. musl owns its return values. OpenSSH owns its comparison. Nobody owned the agreement between them, which is why a single asterisk could mean “this account has no password” in one subsystem and “hashing failed” in the other for ten years without anyone noticing the two meanings had met. Every integration you run has a seam like that. Most of them are fine. None of them have an owner.

Sources

Browse every DNS news article by month →

DNS angle

Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.

Source: Alpine Linux — Security advisory: openssh-server password authentication bypass (2026-11-05).