A long password lets attackers into some Alpine Linux servers

If your business runs a server on Alpine Linux, someone may be able to log into it without knowing a password. They just type a very long one.

The bug, which its finder calls *sshole, is in how OpenSSH checks passwords on Alpine and other systems built the same way. Alpine published an advisory on 5 November, the same day OpenSSH released a fix. “It takes one connection, works every time, and needs no retries,” Alpine says.

Alpine is a small, popular version of Linux. It runs plenty of cloud servers and software containers, and some routers and other devices. If you don’t know whether you have any, ask whoever looks after your servers or hosting.

A password that’s too long to fail

Some accounts on a Linux system aren’t meant to have a password at all. They hold a single * instead. On Alpine, that’s the root account by default since version 3.16, plus users who sign in only with a key.

Alpine uses a lightweight system library called musl. When musl is handed a password longer than 256 characters, it returns * to signal an error. That happens to be exactly what a passwordless account stores. OpenSSH compares the two, they match, and the attacker is in.

The flaw dates back about a decade, to changes in 2012 and 2016 that only became dangerous together. It was reported by Özgün Kültekin of Wakefield. It’s now tracked as CVE-2026-123158.

The OpenSSH team calls its fix a workaround, because “the root cause of this bug” lies outside OpenSSH. musl’s maintainer, Rich Felker, says musl isn’t at fault either, but that the behaviour behind it will very likely change in musl’s next release cycle.

Who is exposed

Every one of these has to be true, according to Alpine:

• OpenSSH runs without PAM. Alpine’s standard openssh-server package is built that way. The openssh-server-pam package is safe unless it’s set to UsePAM no.
• Password logins are on. This is OpenSSH’s default.
• At least one account has no password, such as root, a key-only user or a directory user.
• At least one local account has a real password. In Check Point’s testing, that account also had to be active.

Root itself is protected by OpenSSH’s default rules. But Alpine warns that an attacker who lands in another account can still climb to root if that account has admin rights through doas.

Alpine’s own cloud images for versions 3.18.11 to 3.24.3 need particular care. They ship an alpine user with no password and admin rights. They’re safe on first boot, but become exploitable once any account gets a password, for example a console password or one added through user-data.

You’re not affected if password logins are off or a container doesn’t run an SSH server. Nor are systems using glibc, the library most Linux versions use. Damien Miller of OpenSSH says non-Linux systems and Linux systems using PAM aren’t affected either. Images set up with cloud-init are safe because it switches password logins off.

Beyond Alpine

The same mix can turn up elsewhere. OpenWrt and Buildroot, which are used to build router and device software, both updated their OpenSSH packages to the fixed version on 5 November. OpenWrt normally uses a different SSH server called Dropbear, which isn’t affected.

The finder lists other musl-based systems that are exposed if all the conditions hold. Ars Technica reports it isn’t yet confirmed which other products are affected.

Security firm Detectify said on 5 November it wasn’t aware of public reports of anyone exploiting the bug. But Check Point notes that attackers can see from outside whether a server accepts passwords.

Patch, then restart

Fixed Alpine packages are out for every branch from 3.16 to 3.24, plus edge. Alpine also released versions 3.21.10, 3.22.8, 3.23.8 and 3.24.4 with the fix. Upstream, it’s fixed in Portable OpenSSH 10.6p2.

One catch: Alpine says upgrading the package “does not replace the running daemon”. You have to restart the SSH service. Patched Alpine systems can also still report an older OpenSSH version number, so check the package version, not just the banner.

If you can’t patch straight away, turning password logins off closes the hole. Make sure key logins work first, so you don’t lock yourself out.

If a vulnerable machine was reachable, check its logs. Alpine says to look for “Accepted password for” an account that has no password, such as alpine or root. “If you cannot rule out a login, treat the machine as compromised.”

It’s the lesson of last month’s Plex server attacks again. Anything reachable from the internet needs someone keeping it patched.

Checklist

• Ask who runs your Linux servers. Ask your IT provider or host whether any of your servers, cloud machines or containers run Alpine Linux with SSH switched on.
• Upgrade OpenSSH on every Alpine machine. Run apk upgrade -U -a, then restart SSH with rc-service sshd restart. The upgrade alone leaves the old version running.
• Switch off password logins. Once key logins work, set PasswordAuthentication no, restart SSH with rc-service sshd restart, then check with sshd -T | grep -i passwordauthentication.
• Patch every Alpine cloud machine from 3.18.11 to 3.24.3. Those images ship a passwordless alpine user with admin rights. Update OpenSSH or switch off password logins on each running one.
• Search the logs. Look in /var/log/messages for “Accepted password for” root, alpine or any other account that has no password.
• Treat any machine with a suspicious login as compromised. If the logs can’t rule out a login, don’t keep trusting that machine.
• Ask your router or device supplier. Ask whether its firmware runs OpenSSH on musl, as OpenWrt and Buildroot builds can, and install any update.