A newly disclosed OpenSSH vulnerability has moved from security concern to active threat, with attackers using it to bypass password authentication on certain Linux systems. The flaw, dubbed *sshole and tracked as CVE-2026-123158, can provide unauthorized access to accounts that were deliberately configured without usable passwords—including accounts that may lead to root privileges. Active exploitation has already been observed, only days after the issue became public.
The exposure is narrower than a blanket OpenSSH compromise, but the affected setup is common in lightweight server, cloud, appliance, and embedded environments. A vulnerable machine must use the musl C library rather than glibc, run OpenSSH without PAM authentication, permit password logins, and contain an account whose /etc/shadow entry uses a single asterisk to indicate a locked or passwordless account. Alpine Linux is the best-known example, while some OpenWrt, Buildroot, and Yocto configurations may also qualify. Debian, Ubuntu, and Fedora systems using glibc are not affected by this specific flaw.
The bypass relies on an unusual interaction between OpenSSH and musl’s password-hashing implementation. An attacker sends an oversized password—between 257 and 1,024 bytes—during an SSH login attempt. Under the right conditions, musl returns the same asterisk used in the target account’s shadow entry, causing the authentication check to treat the invalid password as a match. The attack may require two password attempts within one SSH connection, but it does not require prior credentials; knowing an exposed username and reaching the SSH service can be enough.
Researchers have also documented real-world intrusion activity. GreyNoise observed successful exploitation in the wild, while other security companies reported scanning and attack attempts against vulnerable hosts. One tracked campaign, attributed to the group GT10, involved mature intrusions into honeypots in Southeast Asia. Investigators found tooling that included Chinese-language comments and indications that artificial intelligence may have assisted in its development. The attackers’ apparent ability to move beyond simple probing raises the stakes for internet-facing Alpine servers and unmanaged Linux appliances.
OpenSSH addressed the problem in version 10.6p2, released November 5, and Alpine has issued fixed packages for supported branches. Administrators should upgrade the OpenSSH package and restart sshd; installing a replacement package alone does not change the already-running daemon. Alpine’s security guidance also provides patched package versions for older releases.
If an immediate upgrade is impossible, set PasswordAuthentication no in the SSH server configuration and restart the service, after confirming that key-based access works. Operators should keep their existing session open until a new login succeeds, restrict SSH at the firewall or network level, and inspect authentication logs for unexpected password-based access to accounts intended to be key-only. Disabling password authentication is an emergency mitigation rather than a substitute for patching, particularly on systems where SSH is exposed directly to the internet.
