OpenSSH vulnerability: long password opens Alpine

New to this?Ping explains the hardest part in plain words.

Open all explanations

Got an Alpine Linux box with SSH reachable from the internet? CVE-2026-123158 is an OpenSSH vulnerability that lets someone log into an account you deliberately set up with no password, just by sending a password that's too long. The researcher who found it, Özgün Kültekin, named it *sshole, the fix shipped in OpenSSH 10.6p2 on the day it went public, and attackers were successfully exploiting it within 2 days.

#Hackers are already exploiting the OpenSSH vulnerability

Proof-of-concept exploit code showed up about 4 hours after the fix was released on November 5, and exploitation attempts started the same day. GreyNoise, which runs decoy servers built to be attacked, recorded the first successful break-in less than 2 days later and has since logged 16 successful attack chains from 6 source IPs. Once in, attackers looked around the system and its containers, queried cloud metadata services, tried to read password hashes and root's SSH keys, and added their own keys to authorized_keys so they could get back in later.

• A root takeoverOn one decoy, an attacker got root and installed TAC Agent, a Python remote-control implant with Chinese-language comments and logs, then set it up as a startup service. It never reached its command server, so it received no orders.
• Botnets and minerswatchTowr tied the activity it saw to botnets and cryptomining.
• Still smallDefused saw only a small number of attackers trying it, and says the activity isn't widespread.

#How a long password gets past OpenSSH

Linux keeps password hashes in /etc/shadow, and a lone asterisk in that field is the usual way to say "this account never logs in with a password", since an asterisk can't be a real hash. To keep fake and real accounts from failing at different speeds, OpenSSH hashes the attempt even for an account like this, borrowing the salt from another account's real SHA-256 ($5$) or SHA-512 ($6$) hash. On musl, the small C library Alpine uses instead of glibc, crypt() refuses to hash a password longer than 256 bytes for those two hash types, and when it refuses it returns a single asterisk instead of a hash. So sshd gets back *, compares it with the * stored for the account, sees a match and lets the attacker in.

ELI5: explain it simply▾

Ping explainsNo experience needed.

THE WORDS

Hash

A scrambled fingerprint of a password, stored instead of the password itself.

/etc/shadow

The Linux file that holds each account's password hash.

Salt

Random extra text mixed into a password before hashing, stored with the hash.

crypt()

The function that turns a typed password into a hash to compare.

musl

A small C library that Alpine uses instead of the more common glibc.

THE IDEA

Think of a door lock that shows a red X when it's broken, and a door that has a red X painted on it to mean "never opens". The guard checks whether your key's result matches the door's mark. Jam in a key that's too big, the lock breaks and shows a red X, and the guard sees two red X's and waves you through.

Kültekin told BleepingComputer he found the flaw using AI agents that ran about 17,600 authentication tests across different OpenSSH setups, malformed hashes and oversized passwords.

That fits a wider shift: the OpenSSH maintainers have said they now skip long embargoes, because AI tools can rediscover a reported bug within hours.

#Who's affected by the OpenSSH vulnerability

Every one of these has to be true at the same time for a system to be exposed:

• musl without PAMsshd runs on a musl-based Linux and checks passwords itself instead of through PAM. Alpine's default openssh-server package is built this way.
• Password logins onPasswordAuthentication is set to yes, which is the OpenSSH default.
• A passwordless accountAt least one account has a single asterisk as its password field, such as a key-only user.
• A real hash nearbyAt least one other account has a password stored as a SHA-256 ($5$) or SHA-512 ($6$) hash, which is where sshd borrows the salt.

Systems that use glibc, including Debian, Ubuntu and Fedora, aren't vulnerable, and neither is any system that checks SSH passwords through PAM.

#Alpine's cloud images make it worse

Alpine's official tiny-cloud images (the qcow2, VHD and AMI builds) from 3.18.11 through 3.24.3 create an alpine user with an asterisk for a password and passwordless doas, Alpine's lighter take on sudo. If any other account on one of those machines has a password set, the bug can land an attacker in the alpine account, and from there doas hands over root. Images set up through cloud-init are safe from this path, because cloud-init writes PasswordAuthentication no into the SSH config.

#How to check an Alpine server

Run these as root on any Alpine host that runs sshd. They show your installed openssh-server version to compare with the fixed list below, whether password logins are on (including drop-in config files) and which accounts this bug could open. The last three look for signs someone already got in: password logins in the log, SSH keys you didn't add and startup services you don't recognize. An Accepted password line for an account with an asterisk in its shadow field means the system should be treated as compromised.

# installed openssh-server version
$ apk list -I openssh-server
# the password login setting sshd is actually using
$ sshd -T | grep -i passwordauthentication
# accounts with a lone asterisk in the password field
$ awk -F: '$2=="*"{print $1}' /etc/shadow
# past password logins
$ grep "Accepted password" /var/log/messages
# ssh keys that can log in as root or any user
$ cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys
# services set to start at boot
$ rc-update show -v

#How to fix it

Alpine shipped patched openssh packages on November 5 and backported the fix to every branch from 3.16 up, including branches that are already out of support. Update, then restart sshd, because the old daemon keeps running until you do.

• edgeFixed in openssh 10.6_p2-r0.
• Alpine 3.24Fixed in openssh 10.3_p1-r2.
• Alpine 3.23Fixed in openssh 10.2_p1-r1.
• Alpine 3.22Fixed in openssh 10.0_p1-r11.
• Alpine 3.21Fixed in openssh 9.9_p2-r1. This branch reached end of support on November 1.
• Alpine 3.20Fixed in openssh 9.7_p1-r6, even though the branch has been end of life since April.
• Alpine 3.19Fixed in openssh 9.6_p1-r3.
• Alpine 3.18Fixed in openssh 9.3_p2-r4.
• Alpine 3.17Fixed in openssh 9.1_p1-r7.
• Alpine 3.16Fixed in openssh 9.0_p1-r6.

$ apk upgrade -U openssh-server
$ rc-service sshd restart
# confirm the fixed version is installed
$ apk list -I openssh-server

To update everything on the box at once, apk upgrade -U -a works too. If you can't update right away, musl maintainer Rich Felker's advice is to turn off password logins in /etc/ssh/sshd_config and restart sshd, after making sure key logins work. For other musl systems like OpenWrt, Buildroot or Yocto images, the fix is OpenSSH 10.6p2 from your vendor or your own build, with the same config change as the stopgap until then.

#Timeline

opnF.sh

News that matters to the tools we teach.