---
type: "post"
id: "a-researcher-reports-that-openssh-configurations-using-musl-fa9afe"
slug: "a-researcher-reports-that-openssh-configurations-using-musl-fa9afe"
title: "A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for"
description: "A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for certain password-locked accounts when the submitted password was longer than 256 characters."
retrieval_nugget: "A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for certain password-locked accounts when the submitted password was longer than 256 characters. The source says OpenSSH 10.6p2 fixes the flaw and recommends upgrading or disabling password authentication. The finding matters because a configuration intended to permit key-only access could instead admit password-based logins."
published_at: "2026-11-05"
updated_at: "2026-11-07"
record_date: "2026-11-05"
date_kind: "published_at"
topics: ["agent-security"]
entities: ["Alpine Linux","OpenSSH","musl"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
prior_refs: []
source_url: "https://sshhole.com/"
source_urls: ["https://sshhole.com/"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:a-researcher-reports-that-openssh-configurations-using-musl-fa9afe"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/a-researcher-reports-that-openssh-configurations-using-musl-fa9afe/","markdown":"https://newruntime.com/posts/a-researcher-reports-that-openssh-configurations-using-musl-fa9afe.md","json":"https://newruntime.com/posts/a-researcher-reports-that-openssh-configurations-using-musl-fa9afe.json"}
markdown_url: "https://newruntime.com/posts/a-researcher-reports-that-openssh-configurations-using-musl-fa9afe.md"
---

# A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for

## Retrieval answer

A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for certain password-locked accounts when the submitted password was longer than 256 characters. The source says OpenSSH 10.6p2 fixes the flaw and recommends upgrading or disabling password authentication. The finding matters because a configuration intended to permit key-only access could instead admit password-based logins.

## Summary
A researcher reports that OpenSSH configurations using musl without PAM could accept arbitrary passwords for certain password-locked accounts when the submitted password was longer than 256 characters. The source says OpenSSH 10.6p2 fixes the flaw and recommends upgrading or disabling password authentication. The finding matters because a configuration intended to permit key-only access could instead admit password-based logins.

## What happened
The report, published at sshhole.com, describes a flaw in SSH authentication on musl-based Linux systems, including Alpine Linux, OpenWrt, Buildroot and Yocto. It says the issue affects OpenSSH when it runs without PAM, password authentication remains enabled, and an account’s password field contains a single asterisk (`*`). The report names key-only accounts, LDAP users and root as examples of accounts that may use this locked-password marker. It also says Alpine’s OpenSSH server does not use PAM by default, though operators can configure `UsePAM no` elsewhere.

The behavior depends on how the components handle failed password hashing. The source explains that musl’s `crypt()` returns `*` when it cannot process a password longer than its 256-byte limit. OpenSSH uses a salt from another account in some checks, according to the report. In the affected path, the returned asterisk can match the asterisk stored for an account that is supposed to reject password login. The result, the researcher says, is that an attempt with any password between 257 and 1024 characters may be accepted for that account. The headline’s 300-character example is one instance of that range, not a requirement that the password contain a particular character.

The researcher says they tested OpenSSH builds across combinations including glibc and musl, with and without PAM, and with and without shadow passwords. They report sending about 17,600 unusual login attempts through those builds; only musl without PAM produced the unexpected acceptance. The source identifies Alpine’s official AWS and Azure images as particularly concerning: it says their default user can have passwordless `doas`, making access to that account a route to elevated privileges. It says fresh systems with no password fields set are not affected and that systems using glibc, PAM, Dropbear or OpenBSD are outside the described vulnerable configuration.

The source says OpenSSH 10.6p2 fixes the issue. Its immediate mitigation for systems that cannot yet be upgraded is to disable password authentication in SSH configuration and restart the SSH service. It also advises operators to check logs for successful password authentication to an account that should have no password. The page does not provide a CVE identifier, a release date for 10.6p2, or a count of affected installations.

## What the archive adds
New Runtime previously covered Alpine Linux’s report of attempted exploitation of a different vulnerability against its GitLab instance, in [Alpine Linux says attackers tried to exploit CVE-2026-97229 on its GitLab](https://newruntime.com/posts/alpine-linux-says-attackers-tried-to-exploit-cve-27fae6/). That incident concerned attempted attacks on GitLab, not this SSH authentication flaw. This is a new security event, not a restatement or a new fact in that earlier story.

## Trend signal
This report supports [agent security moves to runtime boundaries](https://newruntime.com/patterns/agent-security-moves-to-runtime-boundaries/) only in a broader infrastructure sense: access control depends on the behavior of the runtime stack and its configuration, not on a prompt or policy statement. It is not an agent-security incident, so the connection is limited rather than direct.

## Why now
The report says a security review had changed nearby OpenSSH code four days before the researcher found the issue. It also describes the flaw as present since 2016, while noting that the affected combination of musl, OpenSSH without PAM and locked accounts may have escaped notice. The source does not establish that the review triggered the discovery or that exploitation has been observed.

## Why it matters
A locked account is often treated as an important layer of access control: operators may deliberately leave password login disabled for root, service users or accounts intended for key-based access. The reported behavior means teams should not assume that a locked password field alone enforces that boundary in every libc and SSH configuration. In the affected setup, an unusually long password can turn an authentication failure into acceptance.

The practical response is configuration-specific. Teams need to identify whether their SSH daemon uses musl, whether PAM is disabled, whether password authentication is on, and whether any accounts use the affected marker. The report also highlights cloud images, where a default account may have elevated privileges through passwordless `doas`. Updating to the stated fixed version is the clearest remedy; disabling SSH password authentication is the source’s interim mitigation. This is a reminder to test the whole authentication path, including libc and account state, rather than treating OpenSSH or the account database in isolation.

## Limits and uncertainty
This is a researcher’s technical report, not an advisory from Alpine Linux or the OpenSSH project in the supplied material. It provides a reproducible account of the behavior and names OpenSSH 10.6p2 as the fix, but it does not include a CVE, a formal vendor impact statement, or a release date. The report’s affected-system description is conditional; it does not mean every Alpine or musl installation is vulnerable. It also does not establish that attackers exploited the flaw in the wild, how many systems meet all the conditions, or whether any observed authentication in logs resulted from this bug. Operators should verify their own SSH, PAM, libc and account configurations.

## Reader takeaway
Do not infer that a locked password field guarantees password-based SSH rejection on every Linux stack. Check the specific combination of musl, OpenSSH without PAM, enabled password authentication and `*`-marked accounts. The source identifies OpenSSH 10.6p2 as the fix; until upgrading, it recommends turning off SSH password authentication and reviewing successful logins to accounts that should not accept passwords.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Agent Security](https://newruntime.com/topics/agent-security.md): Explore the agent-security topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)