OpenSSH Patches a Password Bypass on musl Systems Such as Alpine, Where a 257 to 1,024 Byte Password Logs In to Password-Disabled Accounts, and musl’s Maintainer Says the Bug Is Not in musl

OpenSSH 10.6p2, released on November 5, works around a password bypass in sshd on Linux systems that use the musl C library and run sshd without PAM, which is how Alpine Linux builds its default openssh-server package. On such a system, an account whose password field in /etc/shadow is a bare asterisk (a common way to turn off password logins while keeping key logins) accepts any password between 257 and 1,024 bytes long, as long as another account holds a SHA-256 or SHA-512 password hash. The researcher’s conditions say any valid hash, and our tests below show that the hash type matters. Özgün Kültekin of Wakefield found the flaw and calls it *sshole. OpenSSH’s release notes call 10.6p2 “a critical security workaround,” while musl’s maintainer wrote that “this is not a bug in musl.”

The parties disagree about who owns the bug, so we read the code in all three places: sshd, musl and Alpine’s packaging. We also compiled musl 1.2.6’s own password-hashing source on Windows and drove it with a line-by-line model of sshd’s password check. The model reproduces the 257 to 1,024 byte window, shows that the type and the order of the other account’s hash matter, and shows that the OpenSSH fix works by refusing short stored fields no matter what crypt() returned. It is a model of sshd’s decision, not a run of sshd, and nothing here touched a real system.

Who is affected

The researcher’s page, BleepingComputer and The Register give the same conditions, and each one maps to a line of code below:

• sshd runs on a musl-based system. The researcher names Alpine Linux, OpenWrt, Buildroot and Yocto.
• PAM is off, either because the package is built without it (Alpine’s default openssh-server, which its init script swaps for the PAM build only when the configuration says UsePAM yes) or because of UsePAM no.
• Password authentication is on, which is OpenSSH’s default.
• An account has a bare * as its password field. The researcher’s examples are root, a key-only deploy user, LDAP users and the default user on Alpine’s AWS and Azure images.
• Another account has a real password hash. The researcher and both outlets say any valid hash. Our tests below found that SHA-256 and SHA-512 hashes work and MD5 does not.

Systems on glibc, systems that run sshd through PAM and Dropbear are not affected, according to the researcher, and musl’s maintainer adds that “Dropbear and other non-OpenSSH software using password-based logins is not affected.” The Register reports “no indication that vulnerable systems have been exploited.”

How a bare star becomes a match

Three pieces of code, written years apart, meet in this bug.

musl: when crypt() fails, it returns a star

In August 2012, musl changed crypt() to stop returning NULL, a value many callers never check. The commit is titled “make crypt return an unmatchable hash rather than NULL on failure.” In musl 1.2.6 the MD5, bcrypt, SHA-256 and SHA-512 modules each return the string * when they cannot produce a hash. The DES module, which handles every setting that is not one of the four $ forms musl implements, adds one guard: a setting that itself starts with a star gets x back instead.

Twenty days after that commit, musl added SHA-256 and SHA-512 crypt. The SHA-512 code in 1.2.6 refuses keys longer than 256 bytes and returns the star whenever anything fails:

#define KEY_MAX 256
/* ... */
	/* reject large keys */
	for (i = 0; i <= KEY_MAX && key[i]; i++);
	if (i > KEY_MAX)
		return 0;
/* ... */
	p = sha512crypt(key, setting, output);
	/* self test and stack cleanup */
	q = sha512crypt(testkey, testsetting, testbuf);
	if (!p || q != testbuf || memcmp(testbuf, testhash, sizeof testhash))
		return "*";
	return p;

sshd: a star is too short to be a salt, so sshd borrows one

In July 2016, OpenSSH changed how a non-PAM sshd handles passwords to close CVE-2016-6210, a timing difference that revealed which usernames exist. The commit message states the idea: “To mitigate, use the same hash algorithm that root uses for hashing passwords for users that do not exist on the system.” The same path handles a real account whose stored field is too short to serve as a salt. In sys_auth_passwd() the stored field is used as the salt only if it has two or more characters. A bare star has one, so sshd passes no salt, xcrypt() calls pick_salt(), and pick_salt() copies the hash type and salt of the first account in the password database that has a $ hash. The result is then compared with the stored field:

	if (authctxt->valid && pw_password[0] && pw_password[1])
		salt = pw_password;
	encrypted_password = xcrypt(password, salt);

	/*
	 * Authentication is accepted if the encrypted passwords
	 * are identical.
	 */
	return encrypted_password != NULL &&
	    strcmp(encrypted_password, pw_password) == 0;

With a $6$ salt borrowed from another account and a password of 257 bytes or more, musl returns *, which is exactly what is stored, and sshd accepts the password.

Two limits set the window, and one rule shields root

The low end is musl’s 256-byte key limit. The high end is sshd’s own: auth_password() returns early for a password longer than MAX_PASSWORD_LEN, which is 1,024. The researcher’s page gives the same range as “between 257 and 1024 characters.” Both checks count bytes, so a password with multi-byte characters reaches the window with fewer characters. A separate rule in the same function refuses uid 0 unless PermitRootLogin is yes, and the sshd_config manual gives the default as prohibit-password. That is the caveat The Register states about root.

The star is also the value Alpine chose on purpose. A December 2021 Alpine commit changed its root filesystem build script to mark root with * instead of !, saying that this “still forbids password login but allows logins via ssh keys with pam disabled.” That matches sshd’s own source. Its configure script defines ! as the locked-account prefix on Linux, and without PAM, allowed_user() in auth.c refuses every login, keys included, for an account that looks locked. A bare star passes that test, and it is also the value musl returns when hashing fails.

Three positions on whose bug it is

• OpenSSH. The release notes say “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there,” and the fix commit says “We do not consider the root cause to be within OpenSSH but we are well equipped to avoid it.”
• musl. Rich Felker’s advisory on the musl list, sent at 10:07 (UTC-5, which is 15:07 UTC) on November 5, says “It is my position that this is not a bug in musl just an erroneous use by the caller.” It adds that the mechanism “very likely will be changed in the upcoming release cycle” and closes with “Details to follow soon.”
• The researcher. His page puts the cause in a testing gap between the projects: “openssh tests on openbsd and glibc, musl doesn’t test sshd.”

The OpenSSH change leaves crypt() alone and refuses short stored fields. It is commit 90f9c2f7 on the 10.6 branch (4353fdc4 on master, stamped 21:57 UTC on November 4, about eleven hours before the 10.6p2 tarball’s last-modified time of 08:50 UTC on November 5). It adds a minimum length of 4 for the stored value. This is the master commit, abridged:

--- a/auth-passwd.c
+++ b/auth-passwd.c
@@ -67,6 +68,7 @@ extern login_cap_t *lc;
 #define DAY		(24L * 60 * 60) /* 1 day in seconds */
 #define TWO_WEEKS	(2L * 7 * DAY)	/* 2 weeks in seconds */
 
+#define MIN_PASSWORD_HASH_LEN	4
 #define MAX_PASSWORD_LEN	1024
 
 /*
...
@@ -221,7 +227,10 @@ sys_auth_passwd(struct ssh *ssh, const char *password)
 	 * Authentication is accepted if the encrypted passwords
 	 * are identical.
 	 */
-	return encrypted_password != NULL &&
+	ret = encrypted_password != NULL &&
+	    strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
 	    strcmp(encrypted_password, pw_password) == 0;
+	freezero(pw_password, strlen(pw_password));
+	return ret;
 }
 #endif

A bare star has length 1, so it can never match, whatever crypt() returns. The commit also copies the stored field and wipes the copy after use.

What we ran

We downloaded the musl 1.2.6 release tarball from Alpine’s distfiles mirror (its SHA-512 is the one listed in Alpine’s musl APKBUILD), compiled the unmodified hashing files under src/crypt into a DLL with the zig compiler on Windows 11 (with two header stand-ins and a one-function wrapper that are not musl’s), and called its crypt() from Python. The build reproduces the published SHA-512, SHA-256 and MD5 crypt test vectors for the input Hello world! with the salt saltstring. The OpenSSH half is a Python rewrite of three functions that follows pick_salt(), sys_auth_passwd() and auth_password() as they stood before the fix, with the length check from the commit above switched on for the fixed runs. _lib is the loaded DLL:

MAX_PASSWORD_LEN = 1024        # auth-passwd.c: #define MAX_PASSWORD_LEN 1024
MIN_PASSWORD_HASH_LEN = 4      # added by the fix commit

def crypt(key: bytes, setting: str) -> str:
    return _lib.musl_crypt(key, setting.encode()).decode("latin-1")

def pick_salt(db, bcrypt_branch=True):
    """openbsd-compat/xcrypt.c pick_salt(): salt type of the first account with a $ hash."""
    salt = "xx"
    for _name, passwd in db:
        if passwd[:1] == "$":
            p = passwd.rfind("$", 1)               # strrchr(passwd + 1, '$')
            if p != -1:
                typelen = p + 1                    # p - passwd + 1
                if bcrypt_branch and passwd[1:2] == "2" and len(passwd) - (p + 1) >= 22:
                    typelen += 1 + 22              # the October 30 bcrypt branch
                salt = passwd[: min(typelen, 32) - 1]   # strlcpy(salt, passwd, MINIMUM(typelen, 32))
                break
    return salt


def sys_auth_passwd(password, stored, db, fixed=False, bcrypt_branch=True, valid=True):
    """auth-passwd.c sys_auth_passwd(), with the fix switched on by fixed=True."""
    if stored == "" and password == b"":
        return True
    salt = stored if (valid and len(stored) >= 2) else None      # pw_password[0] && pw_password[1]
    setting = salt if salt is not None else pick_salt(db, bcrypt_branch)
    encrypted = crypt(password, setting)                          # musl never returns NULL
    if fixed and len(stored) < MIN_PASSWORD_HASH_LEN:
        return False
    return encrypted == stored


def auth_password(password, stored, db, uid0=False, permit_root="prohibit-password", **kw):
    """auth-passwd.c auth_password(): length cap, root rule, then the system check (UsePAM no)."""
    if len(password) > MAX_PASSWORD_LEN:
        return False
    ok = True
    if uid0 and permit_root != "yes":
        ok = False
    if password == b"":
        return False
    return sys_auth_passwd(password, stored, db, **kw) and ok

First, what crypt() returns for different settings and key lengths:

musl’s SHA-256 and SHA-512 code fails at 257 bytes, while MD5, bcrypt and DES did not fail at any length we tried, up to 1,025 bytes. A bare star passed as the setting returns x at every length, so a program that hands the stored field straight to crypt() cannot be fooled this way. That fits musl’s statement about Dropbear, though we did not read Dropbear’s source. sshd is different because it swaps in another account’s salt.

Second, whether the account alpine:* accepts a password of each length for different shadow file contents, using sshd’s logic through 10.6p1:

Ordinary logins are unchanged by the fix: in the model a correct password for a normal account is accepted and a wrong one refused, before and after. Beyond the reported window, the model shows five more things:

• The hash type matters. Only SHA-256 and SHA-512 settings fail on long keys. If the first $ hash in the password file is MD5 or a type musl does not implement, the model refuses the long password. A traditional DES hash does not start with $, so pick_salt() skips it and falls back to a DES salt, which musl never fails on.
• The order matters. pick_salt() takes the first $ hash in password file order, so a file that lists an MD5 account before a SHA-512 account was safe in the model and the reverse order was not.
• Only a bare star matched. With a 300-byte password the model refused !, !!, !*, x, NP, *LK* and an empty field.
• Root stayed refused under PermitRootLogin prohibit-password and no and was accepted only under yes.
• A bcrypt-only password file is a separate case. The branch of pick_salt() that keeps a whole bcrypt prefix arrived in an October 30 commit on master, which is not in the 10.6 branch or in the older tags we checked (10.0p1, 10.5p1 and 10.6p1). Without it, sshd hands musl a bcrypt setting that is cut short, musl rejects it and returns the star for any key length, and the model accepts any password up to 1,024 bytes for a star account when the only hash on the machine is bcrypt. None of the sources we read mention this, and we did not measure how common bcrypt-only files are on musl systems. The 10.6p2 length check refuses it too.

The test has limits. It is a model of sshd, built from the source lines quoted above, around musl code that was compiled with a different toolchain and operating system than Alpine uses. We did not run sshd, apk or busybox, and we did not launch an Alpine image.

Which systems have a fix

As of about 19:50 UTC on November 5, from the Alpine package index and public commit logs:

Alpine’s stable branches kept their upstream versions: the index shows 10.3_p1 on 3.24 down to 9.7_p1 on 3.20, and the 3.24 diff raises pkgrel and adds the upstream commit as pw.patch. The version string on those systems will therefore not say 10.6p2, so compare the package release with the table. The 3.20 and 3.21 rows are past their end-of-life dates, and Alpine patched them anyway. A package build on a branch does not update a running machine; each one needs its own upgrade.

The OpenSSH tarball’s last-modified time is 08:50:54 UTC on November 5, and the Alpine 3.20 build is stamped about two hours earlier, so Alpine’s first stable-branch package was built from the patch rather than from the release. The portable GitHub mirror still had no V_10_6_P2 tag at 19:50 UTC, which matters to anyone who pins builds to git tags instead of the tarball.

Alpine’s cloud images

The researcher says the default alpine user on Alpine’s official AWS and Azure images is exposed and has passwordless doas, so a login as that user would be root. Alpine’s image build repository supports the parts we could read. Its scripts/setup creates the image user with adduser -D, adds it to the wheel group, sets its password field with chpasswd -e to a bare *, and writes permit nopass :wheel into doas.d when doas is installed. Tiny Cloud’s init script creates the cloud user the same way when it does not already exist.

The default server there is the one built without PAM: Alpine’s openssh APKBUILD configures it with --without-pam and ships the PAM build as a separate openssh-server-pam package. We searched both image repositories, and Alpine’s openssh APKBUILD and patches, for a password-authentication setting. The only one is in apkovl_bootstrap.py, a helper for Packer’s build machine, so the shipped image keeps OpenSSH’s default of password logins on. The cloud-init flavor of the images also installs openssh-server-pam, but the init script starts the PAM build only when the configuration says UsePAM yes and we found no such setting in the image scripts, so we cannot say that flavor is outside the conditions. The same scripts/setup also runs passwd -l root after setting root to a star. We did not test what that leaves in the root field, and root is refused by the default PermitRootLogin anyway.

What to do now

On Alpine the researcher’s fix is to upgrade, and his workaround for anyone who cannot is to turn off password logins. musl’s advisory gives the same workaround and adds a precondition: restart sshd “after ensuring you have working pubkey access.” Alpine’s include-config-dir.patch puts an Include for sshd_config.d at the top of sshd_config, so a drop-in file is read first. The sshd manual says -T will “output the effective configuration to stdout,” which is the way to confirm that the setting took effect.

# Alpine: commands from the researcher's page (we could not run them here)
apk upgrade openssh

# Cannot update yet: turn off password logins, then restart sshd
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
rc-service sshd restart

# Confirm the effective setting (sshd -T prints the effective configuration)
sshd -T | grep -i '^passwordauthentication'

To look for signs of use, the researcher suggests checking whether any account that should not take a password recently did. This loop does that on Alpine’s defaults, where, per BleepingComputer’s account of the researcher’s write-up, sshd logs to /var/log/messages. We ran it against dummy shadow and log files and it printed exactly the one planted line for a star account with an Accepted password entry, and nothing for a clean log:

SHADOW=/etc/shadow
LOG=/var/log/messages
# accounts whose password field is a bare star, then any password login recorded for them
for u in $(awk -F: '$2 == "*" { print $1 }' "$SHADOW"); do
  grep "Accepted password for $u " "$LOG"
done

A hit means a star account took a password, which should be impossible, so treat it as an incident. A log with no hit proves little if the log has rotated or sshd logs somewhere else.

What is still open

• musl’s change. The advisory says details will follow and that the mechanism will very likely change in the next release cycle. Until then, other programs that compare crypt() output with a stored field are unexamined, although musl says non-OpenSSH software is not affected.
• A CVE. None of the sources we read gives one, and Alpine’s secfixes list for openssh has no 10.6_p2 entry.
• Use in the wild. The Register reports no indication of exploitation, and the researcher writes that “so as far as anyone knows, nobody noticed.” Neither is evidence of absence.
• How it was found. The researcher says he had “agent swarms” throw about 17,600 logins at sshd builds. OpenSSH’s release notes say it has received “a large number of security bug reports,” many of them from AI models or made with AI assistance, and will be “making more frequent releases.” The October 30 commit above carries the credit line “Anthropic ANT-2026-7T6M8N4X.” Our curl 8.23.0 report covered another project’s release that credited Anthropic for a high-severity bug.
• Yocto and other builders. OpenEmbedded-core master had no 10.6p2 commit at the time of our check, and we did not check downstream firmware vendors.

For another case where the fix lived outside the application under attack, see our report on the GitLab flaw that needed a patched Ruby.