A star matches a star: the OpenSSH bypass on Alpine, and why patch windows just got shorter

On November 5, OpenSSH shipped 10.6p2, an emergency release for a password bypass in sshd. It doesn't affect most Linux servers. It does affect a very common one: Alpine Linux, and other systems built on the musl C library, when they check passwords without PAM.

On those systems, an account that should never accept a password would accept any password between 257 and 1,024 characters.

The bug itself is interesting. The way it was disclosed is more important.

According to OpenSSH's release notes, the bypass affects "Linux systems that use the musl libc and PAM disabled." It was reported by Özgün Kültekin of Wakefield.

A machine is exposed when all of these are true (PrivacyAffairs, SecurityOnline):

• sshd runs on musl. Alpine is the main case. Buildroot, Yocto and OpenWrt builds that use OpenSSH can be affected too.
• sshd checks passwords itself. Alpine's standard openssh-server is built without PAM. A PAM build with UsePAM no counts too.
• Password login is on. PasswordAuthentication yes is the OpenSSH default.
• Some account has only * in /etc/shadow. That's the usual "no password" marker for key-only users, LDAP users and, since Alpine 3.16, root.
• At least one other account has a real SHA-256 or SHA-512 password hash.

Not affected: glibc distributions (Debian, Ubuntu, Fedora and most others), systems that use PAM for passwords, OpenBSD, and Dropbear. Alpine containers that don't run sshd are also safe.

Where the risk is highest: Alpine's official cloud images. Tiny Cloud creates a default alpine user with * as its password and passwordless doas. Once any account on that box has a real password, an attacker can log in as alpine and then become root.

Neither Alpine, OpenSSH nor the researcher reports exploitation in the wild, and no CVE had been assigned at the time of writing.

No single change caused this bug. It took three changes, each reasonable on its own, made years apart:

• 2012, musl. crypt() returns * on failure instead of NULL, because many programs never checked for NULL and crashed. Weeks later, musl's SHA-512 got a 256-byte input limit to stop very long passwords from tying up the CPU. Over the limit, hashing fails and returns *.
• 2016, OpenSSH. To fix a timing leak that revealed which usernames exist (CVE-2016-6210), sshd hashes the password even when an account has no usable hash, using another account's salt.
• 2022, Alpine 3.16. Root's password field changed from ! to *.

Put them together. A long password is hashed with a borrowed SHA-512 salt, musl gives up at 256 bytes and returns *, and sshd compares that with the stored *. They match, and the login succeeds.

OpenSSH says the root cause is outside sshd. musl's maintainer says it isn't a musl vulnerability. Each component did what it was designed to do. The problem only appeared in one build combination that nobody was testing. Kültekin found it by building sshd in every glibc/musl and PAM/no-PAM combination and sending it about 17,600 unusual login attempts with what he calls "agent swarms."

The fix in 10.6p2 is a workaround: sshd refuses a match when the stored value is shorter than four characters.

Serious bugs usually go through an embargo first. Distributions get the patch privately, and the public hears about it once packages are ready. The distros list allows up to 14 days.

This time OpenSSH heard about the bug roughly a day before it shipped the fix. Alpine's fixed packages landed between 06:53 and 09:05 UTC. Damien Miller announced the release at 09:03 UTC and told affected admins to turn off password authentication or SSH immediately.

The release notes explain why. The team is getting "a large number of security bug reports," many from AI models. It has also seen bugs found by AI tools independently rediscovered by other researchers, and it concludes that attackers who don't report bugs can probably find them too. Miller went further: rediscovery sometimes happens within hours, so OpenSSH now calls long embargoes "a dangerous practice that primarily benefits attackers." For now, it will ship fixes in more frequent releases.

This bug was also found with agents.

For defenders, the advance warning is getting shorter. If finding a bug takes hours, the safe assumption is that someone else has it too. That leaves two things you control: how quickly you notice a fix, and how much of your fleet was ever exposed.

Aeon runs security skills as scheduled agents in your own GitHub repo. Here's where that helps with a bug like this one.

• Exposure is configuration, and configuration lives in repos. All the conditions above (Alpine base image, openssh-server without PAM, password auth left on, a baked-in password) are visible in Dockerfiles, Packer templates, cloud-init and sshd_config files before anything is deployed. That's the territory where vuln-scanner already runs, with dependency CVE checks and secret matching on a schedule.
• Shorter embargoes mean more frequent checks. A quarterly config review assumed you'd have weeks of notice. A daily scheduled check fits a world where fixes ship about a day after the report.
• Aeon also finds bugs this way. vuln-scanner sends code flaws to private vulnerability reports, never public issues, and vuln-tracker follows up every day until each one is fixed. OpenSSH's notes say what maintainers need from AI reports: human triage, realistic threat models, test cases and, ideally, a proposed fix. If more bugs are found faster, the disclosure has to be cleaner too.

A check you can schedule today (a recipe, not a shipped skill). Run it against your infra repos and flag any file that matches more than one condition:

# Alpine base images that install a non-PAM sshd
grep -rnE '^FROM .*alpine' --include='Dockerfile*' .
grep -rnE 'apk add[^#]*openssh(-server)?\b' --include='Dockerfile*' .

# sshd configs that leave password auth on (or never set it; the default is yes)
grep -rnE '^\s*PasswordAuthentication\s+yes' .
grep -rLE '^\s*PasswordAuthentication\s+no' --include='sshd_config*' .

# images or provisioning that set a real password (chpasswd / passwd / hashed $5$ $6$)
grep -rnE 'chpasswd|passwd .*--stdin|\$[56]\$' --include='Dockerfile*' --include='*.sh' --include='*.yaml' --include='*.yml' .

A match is a lead, not a finding. The conditions are in the "What broke" list above.

• Update and restart. On Alpine, run apk update && apk upgrade, then rc-service sshd restart. Upgrading the package doesn't replace the daemon that's already running. Fixed builds are available back to 3.16 (for example 10.6_p2-r0 on edge and 10.3_p1-r2 on 3.24).
• Rebuild images. Any Alpine-based container that runs sshd needs a new build to pick up the fixed package.
• Can't update? Turn off password login. Set PasswordAuthentication no and check Match blocks, which can turn it back on. Confirm your key login works first, then check the result with sshd -T | grep -i passwordauthentication.
• Look for past use. Run grep "Accepted password" /var/log/messages. If an account that logged in that way has only * in /etc/shadow, treat the machine as compromised.
• Keys only on internet-facing hosts. You probably don't need password SSH, and you never did.

A long string of As getting a root shell makes a good clip. What matters more is the timeline. The bug was found with agents and fixed a day later. It was disclosed early because the maintainers expect attackers to find the same bugs just as fast. Plan your patching around that.

Sources: OpenSSH release notes, Alpine security advisory, The Hacker News, SecurityOnline, PrivacyAffairs, Cybersecurity News.