At 08:00 Beijing Time on November 10, 2026, the United States Cybersecurity and Infrastructure Security Agency (CISA) added the OpenSSH authentication bypass vulnerability CVE-2026-123158 to its Known Exploited Vulnerabilities (KEV) catalog and set a remediation deadline of November 12. The catalog entry also indicates that forensic triage is required. Security firm Previdian reported that its sensors recorded 20 attempts to exploit the vulnerability between November 6 and 8, involving 13 attacker IP addresses distributed across 9 countries. These two updates shift the focus of reporting from vulnerability disclosure to actual attack activity; however, the 20 attempts do not equate to 20 successful breaches, and the 9 countries are not necessarily where the victims are located.
Excessive Input and Error Value Matching
Alpine announced that attackers must be able to connect to the target SSH port and know an account name with a password field marked by asterisks. The target machine must also have at least one local account using a password hash in $5$ or $6$ format. Once these prerequisites are met, attackers can submit passwords between 257 and 1024 bytes in length without needing to know the actual password of the target account to pass authentication; this description does not apply to ordinary accounts with valid password hashes. Alpine stated that in a qualifying environment, only one connection is needed, and it does not rely on repeated retries.
The technical root cause lies at the intersection of sshd and musl's password handling. Without PAM, sshd calls the C library's crypt() function to compute the input and compare it with the stored value; when the input exceeds 256 bytes, musl's crypt() returns an asterisk as an error value. Accounts without passwords or using only key-based authentication may also have asterisks in the shadow password file, and if both sides match, they are incorrectly judged as successful authentication. OpenSSH attributes the root cause to outside sshd but confirms that it can be exploited via the sshd path and bypassed within it. Alpine explained that sshd also borrows salt values from another account to complete this comparison, and the fix prevents erroneous return values from being treated as successful authentication.
Prerequisites and Exclusions
Simply installing Alpine does not trigger this issue. The conditions listed by Alpine also include PasswordAuthentication remaining set to yes, openssh-server not using PAM or openssh-server-pam with UsePAM set to no, at least one login account having a password field with asterisks, and another local account possessing $5$ or $6$ hash. The official tiny-cloud image remains secure upon first startup, but administrators setting console passwords or adding hashed passwords through user data may meet the combined conditions. The alpine account has passwordless doas permissions, so once logged in, it can further gain root access.
Alpine explicitly excludes multiple common scenarios: sshd not running inside containers, explicit setting of PasswordAuthentication no, openssh-server-pam with UsePAM enabled to yes, accounts locked with exclamation marks, systems without dollar-sign formatted password hashes, and cloud images with password authentication disabled by cloud-init. Debian, Ubuntu, Fedora and other systems using glibc are also not affected by this musl path, therefore the disclosure cannot be generalized to all Linux devices being directly loggable. The root account is also protected by OpenSSH's default PermitRootLogin prohibit-password setting, unless administrators change it to yes.
Patch Versions and Emergency Mitigation
OpenSSH 10.6p2 was released on November 5. Alpine lists corresponding fix packages for versions 3.16 through 3.24 and edge, with 3.24 fixed at 10.3_p1-r2 and edge fixed at 10.6_p2-r0; different stable branches use their respective backported versions. Alpine requires that updates be performed followed by a restart of sshd, and notes that images from version 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later contain the fixes. Running instances of older point versions still require individual updates or disabling password authentication. Backport packages are also available for branches 3.20 and earlier, though some versions have ended regular support.
When immediate upgrades are not possible, Alpine recommends first confirming that key-based login is functional, then setting PasswordAuthentication to no, checking the configuration, and restarting sshd. Administrators can also search system logs for accounts that should not have accepted password logins but show Accepted password records, and review doas usage, newly created users, files, and authorized keys. The official announcement requires treating machines as potentially compromised when abnormal logins cannot be ruled out; this initial recommendation only defines the scope of investigation, with the current exploitation status to be determined by subsequent CISA and Previdian materials. The announcement also provides sshd -t and sshd -T checking methods for verifying configuration and password authentication status.
Known Exploitation Status and Observation Boundaries
CISA added the vulnerability to the Known Exploited Vulnerabilities catalog on November 9, indicating that the agency has evidence of its use in real-world attacks, though the catalog does not provide information about the attacker identity, number of victims, or scope of activities. The entry sets a remediation deadline of November 12, requiring organizations to take mitigation measures according to vendor guidance and assess internet exposure under applicable BOD 26-04 guidance; if no mitigation measures are available, products should be discontinued per applicable guidance. The entry also marks the need for forensic triage and labels known ransomware activity as Unknown, which cannot be changed to confirmed absence of ransomware usage.
Previdian's public sensor page indicates that 20 attempts were observed between November 6 and 8, originating from 13 different attacker IP addresses, with geographic distribution covering 9 countries. The company defines these records as exploitation attempts and explicitly distinguishes between attempts and successes, therefore these numbers cannot be interpreted as 20 devices compromised, 13 attackers, or 9 victim countries; CISA's catalog entry also does not provide an alternative set of figures for activity scope. Ars Technica's authorized public information stream published a new headline, brief summary, timestamp, and link on November 9, with the headline stating that the vulnerability is being exploited; technical impact conditions, patch versions, and mitigation steps remain based on OpenSSH, Alpine, and CISA publicly available materials.