If you run Alpine Linux, OpenWrt, Buildroot or Yocto builds with OpenSSH, an attacker may be able to log in to accounts you locked against passwords, using nothing more than a very long one. The flaw, nicknamed “*sshole”, sits in the gap between OpenSSH and the musl C library. It does not affect glibc systems such as Debian, Ubuntu and Fedora, but it reaches a popular base for containers, cloud images and embedded devices. A fix is out, so the work now is finding what you run and patching it.

What happened

According to BleepingComputer, researcher Ozgun Kultekin disclosed the bug on 5 November 2026 and says it has existed since 2016. It affects OpenSSH servers on musl-based distributions, but only under certain authentication configurations. Kultekin lists specific conditions for exploitation. The coverage does not spell them out, so read his disclosure to see whether your setup meets them. Systems that use PAM authentication are not vulnerable.

Admins often block password logins for an account by putting an asterisk in the password field of /etc/shadow. An asterisk is not a valid hash, so no password should match it. In 2016 OpenSSH changed its behavior to stop attackers from guessing valid usernames through response-time differences. To equalise timing, OpenSSH now runs the hashing step even for accounts with no usable hash.

On musl, the hashing function returns an asterisk when it fails, and it fails when the password exceeds 256 bytes. OpenSSH then sees the returned asterisk matching the stored one and accepts the login. Accounts with real password hashes cannot be bypassed this way. Kultekin says Alpine’s official AWS and Azure images ship a default ‘alpine’ account with passwordless doas privileges, which could give an attacker root. He says AI agents running about 17,600 authentication tests helped him find the bug. OpenSSH 10.6p2 contains the fix.

Why it matters

The bug shows how two reasonable design choices can fail together. OpenSSH treated a returned asterisk as an ordinary failed comparison, while musl used the same asterisk as its error signal. This suggests that each piece looked fine alone, which may help explain how the flaw went unnoticed for so long.

It also shows the cost of a security fix with side effects. The 2016 patch closed a username-enumeration leak and, on one library, opened an authentication bypass. Teams may want to test security patches against every libc and auth path they ship, not only the mainstream one.

The discovery method deserves a note. Systematic testing of many configurations, malformed hashes and oversized inputs turned up a bug that had lasted years. One case proves little, but it hints that similar testing could surface more issues in older, rarely combined code paths.

What it means for you

Start with inventory. Find every host, container image and device that runs OpenSSH on musl. Alpine is common in container bases, and OpenWrt, Buildroot and Yocto often sit inside routers and embedded products. If you ship hardware built on those, check your firmware and plan an update for customers.

Then patch. On Alpine, run apk upgrade openssh, then check the installed package version to confirm you reached OpenSSH 10.6p2 or later. If you cannot update now, set PasswordAuthentication no in the SSH server configuration and restart the service. That is a sound default for any internet-facing server anyway.

If you launch Alpine’s official AWS or Azure images, treat the default ‘alpine’ account as a priority, since it has passwordless doas. Confirm that password authentication is off for it, and consider whether you need the account at all. Review SSH logs for successful password logins on accounts that should not allow them, and compare against the shadow file entry. A success on an account with an asterisk suggests exploitation. Ask vendors of appliances and managed images whether they use musl and when they will ship the fixed OpenSSH.

For wider context on keeping credentials and access paths tight, see our cybersecurity coverage.

What to watch

  • Whether Alpine refreshes its official AWS and Azure images to remove the default account exposure.
  • Firmware advisories from router and embedded vendors that build on OpenWrt, Buildroot or Yocto.
  • Reports of exploitation in the wild, now that details are public.
  • Whether other core libraries yield old bugs to similar AI-driven testing.

Sources