Practitioners report Alpine cloud images accept passwords over 256 characters

• Key-only accounts can accept arbitrary 257 to 1,024-byte passwords on affected Alpine SSH servers; GeoffreyHuntley flagged AWS and Azure images.
• Root access was reproduced on Alpine 3.24 in rauchg's demonstration, which also identified openssh-server 10.3_p1-r2 as fixed.
• Alpine containers without sshd are unaffected, while paul_cal estimated that few public-facing servers met the exploit's prerequisites.

A password set on another account can turn a previously safe Alpine cloud instance into a root-access target. The discovery write-up traces the bypass to a 2016 timing-attack fix and says agent swarms helped find it.

The alpine:3.24 reproduction was built by a coding agent at rauchg's request. A normal wrong password failed, then an oversized password yielded uid=0(root).

Alpine confirmed the bypass in its November 5 security advisory, which identifies four conditions:

• A reachable OpenSSH server using musl without PAM authentication. Alpine's standard openssh-server package is built without PAM.
• PasswordAuthentication yes.
• A target account whose stored password field is exactly *.
• At least one other local account with a $5$ or $6$ password hash, corresponding to SHA-256 or SHA-512 crypt.

Official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine account with a * password field and passwordless doas. They are safe on first boot, but adding a SHA-512 password hash, for example through a console password or user-data, enables the bypass into alpine and subsequent elevation to root.

Direct root authentication requires PermitRootLogin yes; OpenSSH's default prohibit-password blocks that route. It does not protect another vulnerable account with passwordless elevation.

Cloud-init images set PasswordAuthentication no. Containers without sshd, PAM-enabled authentication, and systems without a qualifying local hash are outside this exploit path.

The bypass is an ugly collision between an account marker and a hashing error, described in Alpine's root-cause analysis:

1. An account's stored * is intended to prevent password authentication while preserving key access.
2. OpenSSH borrows another account's salt when the target's password field cannot supply one. The 2016 timing-attack mitigation made password checks take comparable time even without a usable target hash.
3. With the relevant musl hashing implementation, a password longer than 256 bytes makes crypt() return * as an error indicator.
4. The returned * equals the target's stored *, so the password comparison succeeds.

The projects disagree about responsibility: OpenSSH's release notes put the root cause outside sshd, while the musl advisory calls it erroneous use by the caller.

Upstream OpenSSH 10.6p2 shipped on November 5 with a workaround. Alpine's fixed-package list includes backports, so a lower upstream version can still contain the fix:

| Alpine branch | Fixed openssh package |
| --- | --- |
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |

Installing the package does not replace the running daemon. Alpine's remediation explicitly includes rc-service sshd restart; its alternative workaround disables password authentication and restarts the service.

Alpine 3.21 reached end of support on November 1, but the project published fixes through 3.16 for this issue.

Özgün Kültekin of Wakefield, whom OpenSSH credits with reporting the flaw, describes agent-assisted differential testing across three build dimensions:

• C library: glibc versus musl.
• Authentication: PAM versus no PAM.
• Account database: shadow versus no shadow.

Kültekin says agent swarms exercised roughly 17,600 unusual login attempts, varying hashes, account states, and password lengths. The musl build without PAM accepted attempts that the other builds rejected.

The OpenSSH team says independently rediscovered AI findings have prompted more frequent security-fix releases, replacing its previous practice of batching fixes until a planned release. Its stated concern is that adversaries using similar tools can discover the same bugs without reporting them.

Maintainers also say many AI reports lack security impact under realistic threat models. They explicitly welcome reports accompanied by:

• Human triage and analysis.
• Test cases.
• Proposed fixes.