OpenSSH 10.6p2 fixes *sshole, a password bypass on Alpine and other musl Linux systems

OpenSSH 10.6p2, released November 5, fixes *sshole: on musl-based Linux such as Alpine, OpenWrt, Buildroot and Yocto, with PAM off, any password over 256 characters logs in to accounts locked with '*'. Upgrade with apk upgrade openssh, or set PasswordAuthentication no. Debian, Ubuntu and Fedora are not affected.

If you run OpenSSH on Alpine Linux or another system built on the musl C library, upgrade it today or turn off SSH password logins. OpenSSH released version 10.6p2 on November 5 with what it calls “a critical security workaround” for Linux systems that use musl with PAM disabled. Without it, anyone can log in to an account whose password field is a single * by typing any password longer than 256 characters.

Who is exposed

The researcher who found it, Özgün Kültekin of Wakefield, named it *sshole and published a checker, a proof of concept and the patch on GitHub. According to his write-up, a system is exposed only when all of these are true:

• It uses musl: Alpine, OpenWrt, Buildroot, Yocto, postmarketOS, Void (musl) or Chimera.
• sshd is built without PAM. Alpine’s standard openssh-server package is. openssh-server-pam with UsePAM yes is safe.
• PasswordAuthentication yes is set, which is the default.
• At least one account has exactly * as its password, the usual way to lock password logins for root, key-only users and service accounts.
• At least one other account has a real password hash.

Systems using glibc, including Debian, Ubuntu and Fedora, are not affected, and neither are setups that use PAM, according to BleepingComputer. OpenBSD, FreeBSD and macOS are also outside the bug, per the researcher.

The case that should worry cloud teams: BleepingComputer reports that Alpine’s official AWS and Azure images include a default alpine account with passwordless doas rights. On those images, a login as alpine is a path to root.

What to do now

1. Patch. On Alpine, run apk upgrade openssh to get 10.6p2, then restart sshd. The researcher says Alpine’s packages are out.
2. If you can’t patch today, set PasswordAuthentication no in sshd_config and restart sshd. The researcher says that closes the hole completely. If your team logs in with SSH keys, this costs you nothing.
3. Check for past abuse. BleepingComputer gives Kültekin’s method: on Alpine, run grep "Accepted password" /var/log/messages. A password login for an account whose /etc/shadow entry is * means someone used the bug.
4. Don’t forget the appliances. Routers, NAS boxes and embedded devices built on OpenWrt, Buildroot or Yocto may run the same code. If a vendor ships OpenSSH on musl, ask when its firmware update lands.

How a 257-character password opens a locked account

The bug sits between two projects. To stop attackers from guessing valid usernames by timing, OpenSSH changed in 2016 to run a full password hash even for accounts with no usable password, borrowing another account’s salt. musl’s crypt() function, meanwhile, returns * when it fails, and it fails on any password over 256 bytes. So sshd hashes a long password, gets * back, compares it with the stored *, and lets the attacker in. The researcher’s tests show 256 characters rejected and 257 accepted.

OpenSSH’s release notes say the team considers “the root cause of this bug to be outside sshd,” but fixed it in sshd because that’s where it can be exploited. The researcher says the bug works at least back to OpenSSH 7.5p1 on musl from 2017.

Kültekin told BleepingComputer he found it with AI agents that ran about 17,600 authentication tests. OpenSSH’s release notes say it is receiving more AI-assisted bug reports, and that because bugs found by AI tools are being found again independently, it will ship fixes in more frequent releases. Expect more point releases like this one, and keep SSH updates on a short schedule.

The same week, OpenAI said its GPT-6 Cyber model found 81 new high-severity Firefox bugs and 588 unknown Linux kernel flaws.