The goal from an attacker’s perspective is to get this to be true: `$ret = crypt($pw, $hash); $ret == $hash` when called by OpenSSH’s sshd. This is how sshd validates that the user logging in knew the account password.

The `$hash` is the “settings” to the crypt call and will normally look like “$6$--gibberish” for users with passwords set, but could look like “*” or “!” for users not intended to be able to login.

The bug is from the intersection of all of these things:

1. musl can return “*” for errors, rather than leave the return value NULL. Other libc have adopted something like this too, but seem to use a different result “*0”.

2. musl can also return “+” for errors, but only does so if $hash starts with “*”. This is intended to eliminate the possibility of an error causing `$ret == $hash` to be true, however it assumes that applications calling `crypt()` will set $pw and $hash to values corresponding to the `$ret == $hash` comparison to be made immediately afterwards.

3. OpenSSH can be convinced to pass the hash of a different user if the hash is “*” or “!” to avoid timing attacks that can enumerate the user list, so it will set $pw and $hash to correspond to different users. $hash will be a real “$6$--gibberish” style hash in this case, and OpenSSH expects `crypt()` to either return NULL or return a hash string. But now there’s two hashes OpenSSH uses. It does: `$ret = crypt($pw, $hash2); $ret == $hash1`;

4. This should normally not be a problem because OpenSSH will pass in valid $pw and $hash2 that should not lead to errors in hashing, so the $ret that musl generates should be a real hash that cannot match the “*” or “!” $hash1 for the login-disabled user. However as a DDoS mitigation, musl will return error if the password is too long when using SHA-2-based hashes (the default, it seems).

5. This error will result in a non-NULL result of “*” or “+”. Since OpenSSH passed in a real hash ($hash2), musl will return “*”, which compares equal to the actual user hash $hash1 for the disabled-login user.

The OpenSSL adjustment ensures a minimum hash length for the user before logging them in, even if crypt() succeeds somehow.

[1] https://en.wikipedia.org/wiki/In-band_signaling#Computer_dat...

https://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_des...

(hey, this workaround is wrong if the salt is "x"!)

but they forgot to work around it here:

https://git.musl-libc.org/cgit/musl/tree/src/crypt/crypt_sha...

The vulnerable path in musl is only a little bit vulnerable, because "*" is not actually a sha256 encrypted configuration and should not reach this code: musl's crypt(..., "*") will not call that code! Turns out that sshd detects that the password hash is too short and does not forward the salt!

https://github.com/openssh/openssh-portable/blob/master/auth...

Look, no else statement! If that if doesn't get taken, then salt remains NULL. And the sshd code is really quite messy and doesn't keep track of the fact that this code path is inappropriate for validating an existing password hash.

A workaround in the sha256 path in musl wouldn't even have prevented the bug!

I'm going to give some credit to musl for unwisely using "*" and some credit to OpenSSH for having nonsensical control and data flow.

Don't return empty string/asterisk/anything else. Instead, return a failure value.

When absolutely needed, choose the magic string with more caution:

One string showing the SHA-256 of a non-existing hash? It's a good idea for it to be a valid hash. Now we have a new risk: if it's broken once, it's broken for all. So it's a good idea for it to be a random one for each machine and/or account. Even this might have problems I can't think of, but it seems to be as secure as an account with a real password.

If this is not a good decision for some reason, choose something unmistakable: "--ACCOUNT-HAS-NO-PASSWORD--". This is much less likely to be mistakenly used in a different context, is much easier to look up in a code base than "*", and is self-documenting.

This was not security testing as such - mostly latency, performance and hardcore network "can we break it" and "does it comply" stuff, but also a lot of cable and module / line card pulls, pluggable and fiber breaks, random reboots and pre-empting a lot of possible operator inventiveness. At one point we considered SEU bit flip testing on rented cyclotron time.

And always we battled against the top brass urging us to speed up the process and don't bother with "really basic" testing, because we observed software quality going down over the years as the push for release and time to market stared to dominate.

So we always started with sanity testing - and that included oversized password and CLI input strings. Always. And we caught things more than once, but never like this.

We were right after all.

I was able to reproduce this on Alpine 3.23.7 with OpenSSH_10.2p1.

Luckily PermitRootLogin [0] hasn't allowed logins with passwords for root since 2015 [1]. I'm guessing that's at least part of why this went undiscovered for so long.

0: https://man.openbsd.org/sshd_config#PermitRootLogin

1: https://cvsweb.openbsd.org/diff/src/usr.bin/ssh/sshd_config?...

Am I doing anything wrong here?

OpenSSH_10.3p1, OpenSSL 3.5.9 29 Sep 2026

PRETTY_NAME="Alpine Linux v3.24"

- an account with /etc/shadow hash set to '*'

- (note root won't work by default because of PermitRootLogin prohibit-password default)

- attempt twice, first attempt fails second long password is accepted (that took me a while to understand)

In practice passwd -l seems to lock with a ! prefix, and new account without passwords are created with a single ! which is also not affected, I'm not sure how big the impact actually will be in practice and don't understand the recommendation to upgrade urgently right now... Just don't use `*`?

EDIT: ah, some default container images apparently have a default alpine user with that hash, so I guess that's bad for them. This makes a bit more sense now.

Microsoft has historically been one of the leaders on the wrong side of this one, but they have also demonstrated how effective it is to call out badly behaved software and make it annoy the users with UAC. When Vista came out, so many applications needed elevated privileges to run because they were badly designed to write user data in system locations, but now their application was more annoying to use and came with a scary dialog about it making changes to your computer that other better-designed software didn't get.

More often than not if a program didn't actually intend to change system settings it was just a matter of badly chosen default paths which are pretty trivial to fix, but so many vendors just would not do it despite years of complaints from NT admins wanting to not have to spend hours with Process Explorer figuring out specific permissions to grant limited users enough access. Once their failures were put front and center, calling their application out as the one getting things wrong every time the user ran it, they suddenly had motivation to fix it.

A great example is Jedi Academy, a 2003 Quake 3 engine game whose multiplayer is still actively played today (its open-source engine port, openjk, is even in the Debian repos btw). Luigi had two classic scripts for it on his site: Jedi Academy <= 1.011 in-game server buffer-overflow (jamsgbof)¹, which crashed the server just by pushing a string of as past the 1024-byte console buffer, and Quake 3 engine in-game players kicking (q3msgboom)², where a wall of as hit the engine's 1022-char truncation limit and the leftover bytes confused the parser into disconnecting everyone on the server.

Kind of wild that 20 years later, the exact same payload goes from crashing Quake 3 matches from the tilde console to getting root on some SSH servers.

[1] https://web.archive.org/web/20101227181948/http://aluigi.alt... [2] https://web.archive.org/web/20060522175643/http://aluigi.alt...

Were those pictures with links generated using a publicly available tool that we could use, or were it custom (vibe)coded specifically to create this page?

Are these people mad? Why on Earth would anybody indicate error like this?

I fail to see how the attack complexity of this vulnerability is high, as all it requires is attempting an ssh login with a password longer than 256 characters to an affected alpine image with port 22 open. Am I in the wrong?

[0] https://nvd.nist.gov/vuln/detail/cve-2026-123158

Its not asking for trouble, it is there will be trouble, not if but when.

As for the people who say "well, I run SSH on port 942329053052". Well guess what, the bots make short work on that. We tried it at $work as an experiment, multiple bots found it in less than a couple of hours. That's why your SSH config must be hardened, preferably running on a hardened OS too.

As in: "Actually out there"

The hypothetical Alpine exists, yes, but what runs that like that?

[1] https://hachyderm.io/@damienmiller/117563026759098135

Signatures/verification (typically) only provide a boolean guard on what you want to be controlled behavior.

To properly protect against cla controlled behavior, the check must be incorporated into the EXECUTION of the behavior (with a safe fail).

This is hard and I think a lot of pentesters will continue to have lucrative work hunting issues like this down for a long time.

Fundamentally, the problem is the "type" of the verification and the execution.

I settled on this. There is a block comment on the error handling, dating back to just 2023. There is a tiny infelicity in the wrapper in that we rely on the value of errno in the error path, but we do not set errno to zero and check for it being nonzero (evidence that the function set the value).

Applications using crypt directly can do the same thing: if it returns null, that's an error, of course, but don't use the result if it is less than 13 characters: that's also some kind of error token. The classic crypt() puts out a 13 character hash. Everything else is longer.

  static val crypt_wrap(val wkey, val wsalt)
  {
    val self = lit("crypt");
    const wchar_t *cwkey = c_str(wkey, self);
    const wchar_t *cwsalt = c_str(wsalt, self);
    char *key = utf8_dup_to(cwkey);
    char *salt = utf8_dup_to(cwsalt);
  #if HAVE_CRYPT_R
    struct crypt_data *cd = coerce(struct crypt_data *, chk_malloc(sizeof *cd));
    char *hash = (cd->initialized = 0, crypt_r(key, salt, cd));
  #else
    char *hash = crypt(key, salt);
  #endif

    free(key);
    free(salt);

    /* libraries cannot agree on how to report unrecognized or bad hashes:
     *
     * - older glibc versions, other libraries return null
     * - libxcrypt, integrated into newer glibc puts out two
     *   possible failure tokens "*0" or "*1", documenting
     *   that an error token starts with "*" and is less than 13
     *   characters long.
     * - musl uses "*" and "x", the latter being in the valid hash charset!
     *
     * let's go with: null or less than 13 chars means error.
     */
    if (hash != 0 && memchr(hash, 0, 13) == 0) {
      val ret = string_utf8(hash);
  #if HAVE_CRYPT_R
      free(cd);
  #endif
      return ret;
    }

  #if HAVE_CRYPT_R
    free(cd);
  #endif

    uw_ethrowf(error_s, lit("crypt failed: ~d/~s"), num(errno),
               errno_to_str(errno), nao);
  }

Edit: My bad as pointed below this is not in OpenSSH but in musl and it appears in the relase notes https://www.openssh.org/releasenotes.html#10.6p2. I had scrolled straight to the bottom of the website because the animations annoyed me. Still would like a CVE for proper tracking though!

This might be the beginning of the reason we shouldn't be reading the code. It's like in chess engines where the players complain about how weird, alien and unintuitive the moves are. But 100 steps down the line the engine finds some edge case exploit that gives it enough advantage to win.

So we may be crossing a line, right now, where the non-intuitive alien code being generated by agents is seeing edge cases down the line that might allow exploits. And if we "correct" the agent, we may be leaving ourselves open to exploits we don't see and have difficulty understanding.

So AFAIU, you are fine.

From there, even though you were not root, perms on important stuff were wide open: rxwrwxrwx.

which is not to say that crypt() is well designed or specified - it's clearly deficient. but I can't fathom how the OpenSSH maintainers could come to the conclusion that the root cause is "outside OpenSSH itself" when the root cause is that OpenSSH's mitigation of timing attacks rested on faulty assumptions about the return value of crypt().

https://max.levch.in/post/724289457144070144/shamir-secret-s...

> so musl (the libc under alpine) goes ok fine, crypt() just won't return NULL anymore. if it fails, it returns a single character instead.

Considering it's been accepted that crashing if malloc returns a NULL is your fault, did musl really feel the need to accommodate bad implementations like this or is this just AI speculation?

No idea if it's likely to happen though.

Dropbear is unaffected.

1. https://news.ycombinator.com/item?id=50383006

This is just negligent. Not a fan of rewrite in rust, but I find it highly unlikely this would happen in that community.

[0] https://github.com/leonjza/sshhole-lab

the sshd/musl part dates to the 2016 CVE-2016-6210 fix, so other * accounts (key-only users, LDAP users) have been open for 10 years.

the website is amazing, I just think these details would clarify things.

We need to re-think EVERY assumption about security.

[0] https://news.ycombinator.com/item?id=50377221

Edit: It seems to work fine on mobile. I'm not sure why the scrolling behaviour was added on the desktop version of the site

"tl;dr" was a bit of a downgrade though, but that's fine

it's a nice way to promote the company behind it

It starts with a bold claim: "ssh accounts that should not accept a password will accept any password between 256 and 1024 characters". But then it keeps adding qualifiers:

- sshd compiled with musl

- not using PAM

- password logins enabled

- at least one account with '*' as the password "hash"

- at least one OTHER account with a valid password

- server is aligned with 2 ley lines

- hacker is wearing a blue t-shirt and green socks

Ok, the last two are an exaggeration, but still. The conditions are all ANDed, miss a single one and you're fine.

On top of that, as someone else in these comments reminded, the target account needs to have a valid login shell or other exploitable program assigned to it, and these passwordless accounts tend to have nologin or something similar.

To me this seems to fall on the "technically possible, practically very unlikely" bucket, kinda like the PHP vulnerability from the other day. Maybe this has gone unnoticed for so long because it just doesn't happen.

(Of course I could post it a bit obfuscated)

Can we have a “don’t treat me like five/toddler” / “idgaf about the explanation” quick link to a section for adults who need to patch systems?

(And if your reaction is “just scroll down, stupid”, I’m happy to report that with the scroll jacking, I scroll not enough / past the critical sections nine out of ten times.)

Edit: You may want to read https://sshhole.com/#exposure.

At this point I feel embarrassed in front of the AIs.

Corollary: “Nobody looks”

The proof of this corollary is left as an exercise for the reader.

expect more of these

never changed i guess

He mentions that circa 2019, Debian's libcrypt stopped returning NULL and began returning the 2-character string '*0' - he doesn't elaborate, but this was part of a larger migration by many distros. glibc deprecated its own libcrypt so a more agile project that 'could move faster' would take its place [0]. This migration happened in Fedora 28 [1], Arch [2], and Debian bullseye [3].

Unless you specifically compile it with --disable-failure-tokens, on an error libxcrypt will return that 2-character failure token string. [4] [5] This behavior is very old [6], and hasn't been POSIX-compliant since at least POSIX.1-2001, which is based on SUSv2, which is from 1997.

So they've knowingly kept this non-standard backwards compatibility cludge for almost 30 years, and continue to claim it "isn't well standardized" in their man page despite POSIX and glibc existing, but at least it didn't bite them in the asterisk like it did musl. (Yet.) There's a new issue about removing this behavior now. [7]

[0] https://sourceware.org/legacy-ml/libc-alpha/2017-08/msg01257...

[1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcryp...

[2] https://bugs.archlinux.org/task/67312

[3] https://bugs.debian.org/941853

[4] https://manpages.debian.org/stretch/manpages-dev/crypt.3.en....

[5] https://manpages.debian.org/bullseye/libcrypt-dev/crypt.3.en...

[6] https://github.com/besser82/libxcrypt/commit/a1a3cba626843f3...

[7] https://github.com/besser82/libxcrypt/issues/226

Really: from the XZ backdoor in SSH (which went live on some distros) to this...

What's you rationale for calling port-knocking "security through obscurity" and not "defense in depth"?

Put it this way: if I advertize that my server is using port-knocking, that the sequence changes every 30 seconds (like TOTP) and that as soon one sequence is used, it's unusable (so you've only got one attempt to SSH in every 30 seconds, even if you know the sequence)...

Where's the security through obscurity?

But really: even if had musl and PasswordAuthentication allowed (I don't have neither), how would an attacker gets through the port knocking?

More fundamentally the question is: in which way is your system that does not use port knocking more secure than the one who do?

(remember: we're talking about remote exploits by simply having exposed TCP ports open or SSH listening)

Wanna have a talk too about the "solutions" proposed by "security experts" here "because SSH is too old" and that happen to be crufts on top of SSH that had remote root exploitable backdoors? (sorry, holes)

good fucking god. if I get this correctly... you can insta-own any aws/azure instance that was set up with alpine as long as it has ssh enabled, which it probably has.

Can we please now normalize AI usage in development? Just some other day people asked for "NO AI used" badges for software as measure for quality, and praised i.e. NetBSD for being AI-free. Yes, we come from a phase of AI slop, but it has become obvious that there are plenty of legit usecases where AI beats human-only effort nowadays.

- It affects Alpine's openssh-server (built without PAM), or openssh-server-pam with UsePAM no, when PasswordAuthentication is enabled. Alpine says every release they checked is affected, 3.16 through 3.24 and edge.

- Fixed openssh packages are out for all of those, including the older 3.16-3.20 releases. Upgrade and restart sshd (rc-service sshd restart). If you can't upgrade yet, set PasswordAuthentication no.

- To check a box: apk info -v openssh-server for the version, and sshd -T | grep -iE 'usepam|passwordauthentication' for the effective config.

- Containers built FROM alpine that run sshd are easy to miss in an inventory. So are the official tiny-cloud images (3.18.11 through 3.24.3), which ship an alpine user with no password and passwordless doas, so a bypass there means root.

- After patching, look in /var/log/messages for sshd lines saying "Accepted password for" an account that has no password.

alpine stocks are crashing?

musl stocks are crashing?

glibc stonks are up

alternative implementations in general slightly down