CVE-2026-123158, a flaw in the SSH server OpenSSH, was added to the KEV catalog of CISA, the US cybersecurity agency, on November 9, 2026. KEV lists vulnerabilities that have actually been exploited. According to the NVD description, on Linux where sshd uses musl libc (a lightweight C library) and runs without PAM (a Linux authentication component), a password of 256 to 1024 characters can succeed for some account configurations. The example given is Alpine Linux, familiar as a Docker base image.
To tell whether your server is affected, first check whether you run sshd and whether the system is Alpine Linux. According to Alpine Linux's advisory, Docker and other container users who do not run sshd inside the container are not affected. If you run sshd on a server itself or a virtual machine, that exclusion does not apply, so judge by the conditions below. Linux distributions that use glibc, such as Ubuntu, Debian and RHEL-family systems, are outside the condition in the NVD description (musl libc). We have not, however, checked each distribution's own statement. The fixed release is OpenSSH 10.6p2 (published November 5).
Where the score comes from: 8.1 (CVSS v3.1) is the assessment from the CVE record's own side (the CNA, cve@mitre.org) as shown in NVD. The vector is: network, high attack complexity, no privileges required, no user interaction, unchanged scope, and high impact on confidentiality, integrity and availability. When we pulled NVD on November 10, this was the only CVSS entry (we did not see a score from NIST itself). CISA's SSVC assessment lists exploitation as "active", automatable as "no", and technical impact as "total".
What is happening (as far as published)
- ▸CVE-2026-123158: a password authentication bypass in sshd of OpenSSH before 10.6p2 on Linux when it uses musl libc and runs without PAM. Per the NVD description, a password of 256 to 1024 characters succeeds for some account configurations. The weakness type is CWE-394 (unexpected status code or return value)
- ▸The mechanism (per Alpine Linux): sshd without PAM hashes the entered password with crypt() and compares it with the stored value. musl libc's crypt() returns "*" as an error marker when the password is over 256 bytes. An account with no password also stores "*", so the two match and the login succeeds
- ▸What an attacker needs (per Alpine Linux): (1) network access to sshd, (2) PasswordAuthentication enabled (the default), (3) an account whose password field is "*" (such as root or key-only users), and (4) another account with a $5$ or $6$ password hash. Alpine says it takes one connection and works every time. root is protected by the PermitRootLogin default (prohibit-password), but that does not help if another account that can log in is able to become root, for example through doas
- ▸CISA KEV: added November 9, due date November 12 (a deadline for US federal agencies). Known ransomware campaign use is listed as "Unknown"
- ▸Official response: OpenSSH's 10.6p2 release notes say the release avoids a password authentication bypass on some Linux systems built and run without PAM, and that the team considers the root cause to be outside sshd but avoidable there. Alpine Linux published fixed packages in 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and says it also published fixes back to 3.16
What to do today (if you run sshd on Alpine Linux)
- ✓★Check whether you run sshd. Servers, virtual machines, cloud images and small devices such as routers can be affected. Per Alpine Linux, you are not affected only if you do not run sshd inside the container (if you run sshd on a server itself or a virtual machine, that exclusion does not apply)
- ✓★Update the package and restart sshd. Use the commands below. Updating the package alone does not replace the running sshd. The restart is part of the fix (Alpine Linux advisory)
- ✓If you cannot update, turn off password authentication. Find every "PasswordAuthentication" line in sshd_config, set them all to "no" (including lines inside Match blocks), and restart. First confirm that key-based login works, and keep your current session open while you test (the procedure from Alpine Linux's advisory)
- ✓Check the setting. Even if the command below prints "passwordauthentication no," that shows the base setting only. If a "PasswordAuthentication yes" line remains inside a Match block (a way of giving specific users or sources different settings), password authentication stays on for those connections. Look at every "PasswordAuthentication" line in sshd_config (Alpine Linux's procedure changes "yes" to "no" inside Match blocks too)
- ✓Check the logs. Look in /var/log/messages for "Accepted password" lines for accounts that have no password (alpine, root, key-only users). If you cannot rule out a login, treat the machine as compromised, Alpine Linux says
- ✓Check whether you use Alpine Linux cloud images (tiny-cloud). Images from 3.18.11 through 3.24.3 ship an alpine user with no password and passwordless doas. They are safe on first boot, but Alpine Linux explains they become exploitable once any $6$ hash exists, for example when an admin sets a console password
apk upgrade -U -a
rc-service sshd restartgrep -in PasswordAuthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*
sshd -T | grep -i passwordauthenticationgrep "Accepted password" /var/log/messagesThe commands above are Alpine Linux's procedure. Other systems, including embedded Linux such as Yocto, manage packages differently. A third-party post on oss-security says the problem reproduced on a stock Yocto image too, but that is not an official notice from OpenSSH or Yocto, and we could not confirm it. Check your distribution's guidance to see whether your environment uses musl libc.
What we could not confirm
- ▸The fix status of Linux systems other than Alpine Linux that use musl libc. We confirmed that OpenSSH 10.6p2 is the fixed release, but we did not check individually whether each distribution has shipped an update
- ▸Scale and attackers. KEV inclusion shows exploitation was confirmed, but the sources we could confirm gave no counts or attacker details
- ▸Damage in Japan. This article cannot show it
- ▸A score from NIST. The NVD data we pulled on November 10 had only the 8.1 from the CVE record's own side (the CNA)
- ▸The gap between NVD's "256 to 1024 characters" and Alpine Linux's "257 to 1024 bytes." It looks like a difference in how the boundary is counted, but we have not verified it. Remembering "longer than 256 is dangerous" keeps you safe
If you share it, these three lines
- ▸OpenSSH's CVE-2026-123158 was added to CISA's "exploited" catalog (KEV) on November 9. On Linux with musl libc and no PAM (such as Alpine Linux), a long password may let an attacker log in to accounts that have no password
- ▸★If you run sshd on Alpine Linux, update and restart sshd. If you cannot update, confirm key login works and then set PasswordAuthentication to no (container users who do not run sshd inside the container are not affected; sshd on a server itself or a virtual machine can be)
- ▸The fixed release is OpenSSH 10.6p2. Also check /var/log/messages for "Accepted password" on accounts with no password