Policy

An OpenSSH bug lets attackers skip the password on some Linux servers. CISA’s deadline is November 12.

CISA added CVE-2026-123158 to its Known Exploited Vulnerabilities catalog on November 9, with a due date of November 12. It affects sshd built without PAM on systems using the musl C library, such as Alpine Linux. Update to OpenSSH 10.6p2 or your distribution’s fixed package and restart sshd, or turn password logins off.

Edited by Emilio Santos 6 min read
Rows of servers in a data center
A server that accepts SSH passwords needs this week’s update and a restart. Photo: Circuit & Capital

On November 9, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added an OpenSSH flaw, CVE-2026-123158, to its Known Exploited Vulnerabilities catalog. The federal due date is November 12. On affected servers, an attacker who can reach the SSH port can log in to some accounts without knowing the password.

OpenSSH says the bug affects “some Linux systems,” not every server. It applies when OpenSSH is built and run without PAM, the pluggable authentication modules framework, on a system that uses the musl C library. Alpine Linux, a lightweight distribution whose advisory covers servers, containers and cloud images, is the named example. If you run SSH on Alpine, update today and restart the SSH service, or turn password logins off.

What happened

The OpenSSH project released portable OpenSSH 10.6p2 on November 5. Its release notes describe “a critical security workaround that affects Linux systems that use the musl libc and PAM disabled.” The project says it considers the root cause to be outside sshd, the SSH server, but that the bug is exploitable through sshd and can be avoided there. The notes credit Özgün Kültekin of Wakefield with the report.

The National Vulnerability Database entry, published November 5, says sshd before 10.6p2 on Linux, when musl is used without PAM, lacks a workaround for a password authentication bypass, and that for some account configurations any password between 256 and 1024 characters succeeds. The CVSS 3.1 score supplied by the CVE assigner is 8.1, rated High.

Alpine’s security team published its own advisory the same day, and it explains the mechanism in plain terms. Without PAM, sshd checks a password by hashing the attempt with the C library’s crypt() function and comparing the result to the stored password field. musl’s crypt() returns the string * as an error when the input is over 256 bytes. * is also exactly what the stored field contains for an account with no password set. The two match, and the login succeeds. Alpine says it takes one connection, works every time, and needs no retries.

CISA added the CVE on November 9, based on evidence of active exploitation, alongside three other flaws. Its catalog entry is marked for forensic triage, which means agencies are expected to check whether a system was compromised, not only patch it. CISA lists known ransomware use as unknown.

Who is affected

Alpine lists three conditions, and all three must be true:

  • sshd runs without PAM. That is the default Alpine openssh-server package, or openssh-server-pam with UsePAM no. openssh-server-pam with UsePAM yes is not affected.
  • Password logins are on. PasswordAuthentication yes is the OpenSSH default unless someone changed it.
  • The machine has an account whose password field is *, and at least one other account with a $5$ or $6$ password hash. Accounts with * include root on Alpine base images since about 3.16, any key-only user created without a password, and users that come from a directory service through musl-nscd. One account with a real password is enough to make every account without one reachable.

OpenSSH’s default PermitRootLogin prohibit-password protects root itself. Alpine warns that this does not help if another account that can log in is able to become root, for example through doas. The official Alpine tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas. Alpine says those images are safe on first boot and become exploitable as soon as any $6$ hash exists on the machine, for example when an admin sets a console password.

Alpine says every release it checked is affected, 3.21 through 3.24 and edge, plus the older 3.16 to 3.20 releases. It is not affected where containers do not run sshd, where password authentication is off, where no account has a $-style hash, and on cloud images configured through cloud-init, which writes PasswordAuthentication no.

What it means for owners and CISOs

This is a narrow bug with a severe outcome. The population is small compared with a flaw in every OpenSSH install, but the machines that fit it tend to be the ones nobody inventories: a container someone gave an SSH port for debugging, a small Alpine virtual machine a contractor set up, an appliance or edge box built on Alpine. If your provider says “we don’t run Alpine,” ask how they know.

The fix is cheap. Updating a package and restarting a service is minutes of work per machine. The expensive part is the follow-up on any machine that was exposed with password logins on, because a successful login leaves the attacker with a shell, and on tiny-cloud images a route to root. That is why CISA marked the entry for forensic triage, and why “we patched it” is not the end of the conversation.

The release notes also carry a wider signal. The OpenSSH team says it has received a large number of security reports, many from AI models or made with AI assistance, and has seen bugs found by AI tools later found independently by other researchers. For now it will make more frequent releases rather than batching fixes. Plan on more small OpenSSH updates, and make sure someone owns them.

What to do this week

  1. List every machine and container that runs sshd on Alpine or another musl-based system. Include anything a provider manages for you. Write down the answer and who gave it.
  2. Update and restart. On Alpine, run apk upgrade -U -a. Alpine’s fixed packages include 10.6_p2-r0 on edge, 10.3_p1-r2 on 3.24, 10.2_p1-r1 on 3.23 and 10.0_p1-r11 on 3.22, with fixes published back to 3.16. Then restart sshd with rc-service sshd restart. Alpine stresses that upgrading the package does not replace the running daemon.
  3. If you cannot update yet, turn password logins off. Confirm key login works first and keep your current session open. Set PasswordAuthentication no, run sshd -t, restart sshd, and check that sshd -T | grep -i passwordauthentication prints passwordauthentication no. Alpine says either step closes the hole.
  4. Rebuild images. Alpine says images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fixed package. Older point releases do not, so update running instances and rebuild base images and containers.
  5. Check for a past login on exposed machines. Alpine’s advice: look in /var/log/messages for sshd lines reading “Accepted password for” an account that has no password, such as alpine, root or any key-only user. Review doas use and recently created users, files and authorized keys. If you cannot rule out a login, treat the machine as compromised.

Also added to KEV November 9 (due November 12)

CISA added three other flaws the same day, all with the same November 12 due date and all marked for forensic triage: GPUStack CVE-2026-102895, an improper authentication flaw that CISA says could allow unauthenticated administrative access; SignalWire FreeSWITCH CVE-2026-116779, a code injection flaw; and IBM Aspera Faspex CVE-2026-123218, an incorrect authorization flaw that could let an authenticated user escalate privileges. If you run any of them, follow the vendor advisory linked from CISA’s catalog entry.

What to watch next

  • Other musl-based images. The advisories name Alpine. If a product you use ships on a musl-based system with its own SSH build, ask the vendor whether it is affected.
  • More OpenSSH point releases. The project has said it will release more often for now. Track the release notes page rather than waiting for a distribution bulletin.
  • Post-incident detail. CISA has not published who was attacked or how. If vendors or researchers publish indicators, run them against any machine that had password logins on before you patched.

Not sure whether one of your servers, containers or providers fits the conditions above? Our $29 Quick Answer service covers one question like that, in writing.

Sources

Related: Barracuda appliances are on CISA’s exploited list, this week’s patch calendar, and Security and vulnerabilities, every security briefing, guide and tool in one place.

ES
Emilio Santos edits Circuit & Capital. How we source and correct pieces: editorial standards.
circuits50capital@circuits.fit