An attacker who can reach your SSH port on Alpine Linux can log in without knowing any password. Not through brute force, not through a timing attack, not through a clever cryptographic break — through a string comparison that accidentally matches. The bug is deterministic: one connection, every time, no retries. The mechanism is elegant in its awfulness. When OpenSSH is built without PAM — as Alpine's default package is — it checks passwords by hashing the attempt with the C library's crypt() function and comparing the result to the stored password field. For accounts with no password set, that stored field is the single character . When the attacker sends a password longer than 256 bytes, musl's crypt() chokes and returns as an error indicator. The stored field is . The error output is . They match. Welcome in. The preconditions sound narrow but are not. You need an account with a password field — which includes root on every Alpine image since 3.16, any key-only user created with adduser, and the alpine user on official cloud images. You also need at least one other account with a real $5$ or $6$ password hash, which is present the moment any administrator sets a console password or user-data creates a hashed account. The official tiny-cloud images ship safe on first boot but become exploitable the instant someone adds a password to any account on the system. Every Alpine release from 3.16 through 3.24 and edge is affected. Fixed packages are available across all branches, including the no-longer-supported releases back to 3.16. But upgrading the package alone does not fix a running system — the sshd daemon must be restarted manually. If you cannot update, setting PasswordAuthentication no and restarting sshd closes the hole completely. The vulnerability was reported by Özgün Kültekin of Wakefield. OpenSSH maintainers Damien Miller and Darren Tucker produced the fix and the 10.6p2 release. No CVE identifier had been assigned at time of disclosure. Detection is straightforward: look for 'Accepted password' log lines for accounts that have no password set — alpine, root, or any key-only user. This is a supply-chain composition bug, not an OpenSSH bug or a musl bug in isolation. OpenSSH assumes crypt() will not return a valid-looking result on error. musl returns on overlong input. Alpine ships accounts with as the password field. Each decision is defensible alone; together they create a deterministic authentication bypass. The fix in OpenSSH 10.6p2 adds a guard in sshd itself, but the deeper lesson is that implicit contracts between C library functions and their callers remain a live source of critical vulnerabilities. The practical exposure depends heavily on deployment context. Docker containers that do not run sshd are unaffected. Cloud-init systems that disable password authentication are safe. But any Alpine VM, bare-metal server, or cloud instance running the default openssh-server package with at least one real password hash on the system has been silently exploitable for years. If you cannot rule out a login on an exposed machine, treat it as compromised.
