Alpine Linux SSH flaw is being exploited so update and restart sshd now

The Alpine Linux SSH vulnerability we covered in our first Sunday Linux security roundup⁠ now comes with another reason to stop postponing that update. CISA has added the authentication bypass to its Known Exploited Vulnerabilities catalog, confirming that the threat extends beyond a researcher demonstrating what could happen.

Tracked as CVE-2026-123158, the vulnerability entered CISA’s catalog⁠ on November 9. The agency identifies an authentication bypass affecting OpenSSH on Linux, but its entry does not identify the attackers, name victims, or establish how widespread exploitation has become.

That is enough to make affected systems a priority without turning this into a claim that every Linux machine is compromised. The configuration requirements matter, and so does completing the update properly.

GreyNoise has documented attackers exploiting CVE-2026-123158 on its deliberately vulnerable monitoring systems, with the first observed attack on November 7. Its November 9 update records 17 confirmed exploitation chains, including attempts to read password hashes and SSH keys, probe cloud metadata, and deploy a Python implant.

The vulnerability is not exclusive to Alpine: OpenSSH identifies Linux systems using musl with PAM disabled as the affected platform category, although exploitation also requires the vulnerable password authentication and account configuration. These observations do not establish how many production servers have been compromised, but they reinforce the need to patch affected systems, restart sshd, and check for unauthorized access.

According to Alpine’s advisory⁠, affected configurations span releases 3.16 through 3.24 and edge. They combine SSH without PAM, enabled password authentication, a target account whose password field contains *, and another local account with a $5$ or $6$ password hash.

Containers without an SSH server are outside this issue. Using Alpine as a container base does not, by itself, create an exposed SSH service.

Fixed OpenSSH packages include the following:

Alpine also lists patches for older branches. After upgrading, restart the daemon with rc-service sshd restart; installing the package alone leaves the existing daemon running.

If patching must wait, first confirm that SSH key access works, then disable password authentication and restart sshd. Review unexpected password logins to passwordless accounts and suspicious account or authorized-key changes on exposed machines.

The upstream OpenSSH 10.6p2 release notes⁠ explain that the problem affects some Linux systems using musl libc with PAM disabled. OpenSSH’s developers describe the underlying cause as outside sshd, while providing a workaround within sshd to prevent the bypass.

That upstream release arrived on November 5. Its version number should not become a shortcut for judging every distribution package, however, because a distribution can apply the relevant correction to an older supported release.

There is also a broader warning in those release notes. OpenSSH says independent researchers are rediscovering security issues identified with AI tools, leading the project to deliver fixes more frequently rather than wait for its next planned release. That observation does not establish that AI was used in the attacks covered by CISA’s entry, and those are separate claims.

For administrators, the immediate question is whether an exposed system matches the vulnerable configuration and whether the fixed service is actually running. A successful package installation is useful evidence, but it is not the entire maintenance job.

Written by

Brian Fagioli ✔

Technology journalist and founder of NERDS.xyz

Brian Fagioli is a technology journalist and founder of NERDS.xyz. A former BetaNews writer, he has spent over a decade covering Linux, hardware, software, cybersecurity, and AI with a no nonsense approach for real nerds.

📄 More by Brian Fagioli ✖ Follow on X ▶ YouTube @ Threads 🐘 Mastodon