---
title: "On Alpine Linux, the Asterisk That Locked an Account Also Opened It"
description: "A flaw roughly ten years old let anyone who could reach SSH log into passwordless accounts by typing more than 256 characters"
author: "Jan Sokol"
published: 2026-11-05T23:09:36Z
modified: 2026-11-06T15:49:08Z
url: https://rews.cc/a/on-alpine-linux-the-asterisk-that-locked-an-account-also-ope-834e1d
language: en
tags: ["ssh", "linux", "security", "openai", "vulnerability", "tech"]
publisher: "Rews (https://rews.cc)"
---

# On Alpine Linux, the Asterisk That Locked an Account Also Opened It

*A flaw roughly ten years old let anyone who could reach SSH log into passwordless accounts by typing more than 256 characters*

By Jan Sokol · November 5, 2026 · https://rews.cc/a/on-alpine-linux-the-asterisk-that-locked-an-account-also-ope-834e1d

## In brief

- Alpine Linux maintainers disclosed on 5 November 2026 an SSH flaw, about a decade old, allowing passwordless logins
- musl’s crypt() returns an asterisk for inputs over 256 bytes, matching the asterisk stored for passwordless accounts
- Exploitation requires sshd without PAM, password auth on, and another active account with a SHA256 or SHA512 hash
- Root is protected by default, but reachable accounts with doas or sudo rights can still escalate to root
- OpenSSH 10.6p2 and patched Alpine packages fix the bug; sshd must be restarted after upgrading

In /etc/shadow, the file where Linux machines keep their password hashes, a single asterisk can stand where a hash would normally go. It means nobody gets in this way. Accounts that log in with certificates or keys carry it, and administrators trust it the way a household trusts a bolted gate.

On Thursday, 5 November 2026, the maintainers of Alpine Linux said that on some of their systems the asterisk had also been working as a key, for about a decade. As [Dan Goodin reported for *Ars Technica*](https://arstechnica.com/security/2026/11/vulnerability-allows-attackers-to-log-into-some-linux-devices-sans-password/), the flaw lets attackers log into some configurations of Alpine, a lightweight and widely used distribution, and possibly into other systems as well, without any password.

## Two stars that look alike

The fault sits where two programs meet. OpenSSH is the software that accepts remote logins. Unlike most Linux distributions, Alpine is built on musl (pronounced “muscle”), a lean alternative to the usual C library. When OpenSSH runs without PAM, the framework that normally handles authentication and account checks, it tests a password by passing the attempt through a function called crypt() and comparing the result with what is stored for the account. According to [Check Point’s analysis](https://blog.checkpoint.com/exposure-management/a-critical-ssh-password-bypass-hits-musl-based-linux), musl’s crypt() reports an error by returning an asterisk whenever the input is longer than 256 bytes. The passwordless account stores an asterisk as well. The server compares the two, sees the same symbol, and lets the visitor in. Check Point says any password between 257 and 1,024 bytes will match.

![A tangled orange cord stretches across a teal background and connects to an orange knob on an open navy door with light spilling through.](https://rews.cc/img/545949297084feb32c2778d1068aa21e768ce86a.webp)

There is something almost administrative about it. Each office followed its own rulebook. The library reported its error in the form it was told to use, and the server compared the two strings it was given. Nobody checked whether the error message and the lock were written with the same mark.

## The conditions

The door does not open on every machine. sshd has to be running without PAM on a musl-based system. Check Point says that is the case with Alpine’s default openssh-server package, and with the PAM-enabled package when UsePAM is set to no. Password authentication has to be switched on, which is OpenSSH’s default. The target account needs the asterisk in its password field. And at least one other local account has to have a real password hashed with SHA256 or SHA512. That last condition, Check Point said, “matters because sshd borrows that account’s salt. Without it, the attack fails.” The company’s researchers added that their testing showed the account must be active, not just hold a hash.

![Four navy panels with circular openings stand in a row on a yellow background, with a yellow beam passing through them toward a red sphere.](https://rews.cc/img/4c937b0945847a7c3d7270ac7b0314c046831e46.webp)

When all of those conditions hold, the attack is simple enough to be unsettling. The Alpine maintainers put it this way:

> An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.

Passwordless accounts are common, especially for users who log in with certificates or keys. Check Point names key-only users, directory users served through musl-nscd, and the alpine user in the official tiny-cloud images as accounts that carry the asterisk. OpenSSH developer Damien Miller is quoted by the firm as saying that “glibc Linux, non-Linux systems, and Linux with PAM are not affected.” Other platforms that combine musl, OpenSSH and no PAM in the same way may be.

## The road to root

The top account stays protected. Check Point reported that root is safe under the default PermitRootLogin prohibit-password setting, which bars password logins for root. That protection only applies to root itself. Any reachable account with doas or sudo rights can still be used to become root, so getting into an ordinary account can be enough to take the whole machine.

![A red person climbs dark blue stairs decorated with cream keys toward a large cream crown against a bright blue background.](https://rews.cc/img/039be5358dc3150f453f5e39186c190f03cff62b.webp)

## The repair

The fix came quickly. Check Point says OpenSSH shipped release 10.6p2 on 5 November, one day after learning of the bug, and Alpine published patched packages for its 3.16 through 3.24 branches and edge. The patched Alpine packages keep older version numbers, 10.3\_p1-r2 on 3.24 for example, so a version check alone won’t show whether a machine is safe. Upgrading is also not enough: the firm warns that “the package upgrade does not restart the running daemon,” so sshd has to be restarted before the fix takes effect. As of 5 November, Check Point said, no CVE number had been assigned.

For administrators who can’t patch yet, the advice is to set PasswordAuthentication to no. To find out whether anyone has already used the flaw, Check Point suggests searching the logs for “Accepted password for” entries on accounts that have no password, which should never appear.

Like the [16-year-old server boot flaw](https://rews.cc/a/a-9-5-rated-server-boot-flaw-was-supposed-to-stay-secret-unt-aefc28) exposed last month, this one sat in plain view for years in code that thousands of people depend on. On every machine where the upgrade has been installed but sshd has not been restarted, the old process is still running, and it still reads both asterisks as the same thing.