CISA lists OpenSSH CVE-2026-123158 four days after the fix; fixed Alpine packages keep old version numbers

CISA listed the sshole flaw four days after the fix, and the listing does not say who, where or how many

OpenSSH 10.6p2 and Alpine's fixed packages shipped on 5 November 2026. On 9 November CISA added CVE-2026-123158, nicknamed sshole, to its Known Exploited Vulnerabilities (KEV) catalog, four days after the fix (derived: 5 to 9 November). The catalog feed gives 12 November as the due date: three days after the listing and seven days after the fix (both derived). The entry names the flaw "OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability", gives "Unknown" for known ransomware campaign use and "Yes" for forensic triage, and says nothing about who is exploiting it, against which systems, or how many.

That is the gap this briefing is about. A listing tells a defender that CISA holds evidence of exploitation. It does not tell them where the evidence came from, which configuration was hit, or whether any host was logged into. The sources this site could read give three different pictures: Ethiack's page, dated 5 November, said no exploitation in the wild had been reported; Previdian's sensor page, read on 10 November, counts 22 exploitation attempts from 14 addresses and says in the same breath that attempts do not show success; and the CVE record, updated on 10 November, now carries a CISA entry reading exploitation "active". None says who.

The second thing to know is a trap for scanners. Alpine's fixed packages keep older version numbers, so a scanner that compares the installed version with 10.6p2 flags hosts that are already patched. The third is that upgrading the package does not restart the running daemon: Alpine says so in its first lines. Alpine's advisory, the OpenSSH 10.6p2 release notes, the CVE record, NVD and the KEV entry were read in full, and the vendor write-ups of Ethiack and Ostorlab and the Previdian page are secondary sources; Ethiack sells attack surface testing, Ostorlab attack surface discovery and Previdian paid exploitation intelligence, so each is read as a vendor's account of a flaw it has a product for. All times are as read between 10:45 and 11:05 UTC on Tuesday 10 November 2026; the KEV catalog, the CVE record and Previdian's counts can change within the hour.

The clock: what happened when, and who says so

The OpenSSH 10.6p2 release notes are dated 2026-11-05 and describe "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled". They do not carry a CVE number and do not say the flaw was exploited. Alpine's advisory, also dated 2026-11-05, says "No CVE identifier had been assigned at the time of writing." The CVE record shows the identifier reserved at 15:46:25 UTC and published at 15:46:26 UTC the same day, assigned by MITRE as the CVE numbering authority.

Zoom

The four conditions, and who is not affected

Alpine's advisory says an attacker who can reach the SSH port "can log in without knowing any password". It adds that "It takes one connection, works every time, and needs no retries." The attacker needs the name of an account whose password field is * and at least one other account with a $5$ or $6$ password hash, then sends a very long password, 257 to 1024 bytes according to Alpine. Alpine says one user with a password is enough, because it makes every account without one reachable.

Zoom

Root needs a second condition. Alpine says "OpenSSH's default PermitRootLogin prohibit-password protects root", so root is reachable only if PermitRootLogin yes is set; and "That does not help if another account that can log in is able to become root, for example through doas." The tiny-cloud images are the case Alpine spells out: the alpine user there has a * password field and passwordless doas, so the image is safe on first boot and becomes exploitable once any $6$ hash exists, for example when an admin sets a console password.

Who is not affected, in two sentences. Ethiack and Ostorlab say glibc distributions such as Debian, Ubuntu, Fedora and RHEL are not affected, and neither are systems using PAM. Alpine's own list adds containers that do not run sshd, systems with PasswordAuthentication no, and cloud images configured through cloud-init.

The root cause, as the three write-ups print it

When sshd is built without PAM it checks a password by hashing the attempt with crypt(), the C library function that turns a password into its stored hash, and comparing the result with the stored field. For an account whose stored field is too short to hold a salt, sshd borrows the salt of another account, which is why a $5$ or $6$ hash elsewhere matters. Alpine says "musl's crypt() returns the string * as an error indicator when the key is over 256 bytes long." The string * is also what the stored field holds for every account with no password, so the comparison matches and the login succeeds. Ethiack says glibc returns NULL instead, which sshd already rejects.

The OpenSSH release notes say "We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there." The fix, as Ostorlab prints the change, adds a minimum length for a stored hash, so a one character field can no longer match (the diff is under Technical details). Ostorlab also dates the bug: it says it became reachable in 2016, when OpenSSH added a salt picking function as a timing fix for an earlier CVE. That history is Ostorlab's account; this site did not open the OpenSSH or musl commits. The researcher is credited by both OpenSSH and Alpine as being at Wakefield; this site names the organisation only.

One detail differs between sources and it matters to anyone testing a configuration. Alpine says 257 to 1024 bytes. The CVE record and NVD say "any password between 256 and 1024 characters succeeds". Ostorlab explains the gap: a 256 byte key is still accepted by musl and produces a real hash, so 257 is the shortest value that triggers the error return. The units differ too, bytes against characters, and this site does not resolve that.

The fixed packages keep old numbers: the scanner trap

Alpine prints one fixed openssh package per branch, from edge back to 3.16, including the releases that no longer get regular updates. "3.21 reached its end of support on 2026-11-01", four days before the advisory (derived), and Alpine published fixed packages for each release all the way back to 3.16 anyway. The point releases that carry the fix are 3.21.10, 3.22.8, 3.23.8 and 3.24.4. For 3.20 and older Alpine names no point release, so the column says Not stated.

Read the last column. Every stable branch's fixed package carries an upstream number below 10.6p2, because Alpine backports the patch into the version it already ships. Only edge ships 10.6_p2-r0. Ethiack puts the consequence plainly: "Alpine's fixed packages keep older version numbers, so scanners that only compare against 10.6p2 will flag patched Alpine hosts". The CVE record's own range is OpenSSH before 10.6p2. NVD's configuration lists OpenSSH below 10.6 plus 10.6 and 10.6p1, alongside four Alpine ranges (before 3.21.10, 3.22.8, 3.23.8 and 3.24.4) marked as not vulnerable platform entries. Whether a given scanner reads those entries by operating system release or by package revision is not something this site tested; it is this site's inference that a scanner keyed to the OS release would still flag a host that took the patched package without moving to the new point release.

The same trap runs the other way. A host showing a number at or above 10.6p2 is not automatically fine either: the CVE record and Alpine both tie the bug to a build without PAM on musl, and the version string does not say either. This site's inference, not a source's statement: the SSH banner carries the OpenSSH version, not the libc or the PAM setting, so a banner cannot separate an affected Alpine host from an unaffected Debian one. Ethiack says its own scanning checks "how each server behaves rather than its version banner alone", which is its product claim and was not tested here.

And a patched package on disk is not a patched daemon. Alpine: "Upgrading the package alone does not replace the running daemon." Its own instruction is to restart sshd after upgrading.

What each source states about exploitation, and what it leaves out

This is the table to keep. Each row is a source, what it states about exploitation, and what it does not. The right hand column is this site's reading of the silence and does not claim that nothing happened; CISA may hold evidence it has not published. What can be said is that no page read here names the party, the number of hosts or the system type.

Two items in the table deserve a second look. The first is the ISC diary. The CISA entry in the CVE record lists an ISC diary as a reference, and NVD tags that reference as not applicable. This site opened it on 10 November: it is about attackers searching for SAP NetWeaver webshells and does not mention OpenSSH or this CVE. The reference may have pointed at a different diary when it was added; this site cannot tell. The record also lists a GreyNoise page; its host answered 403 to this site's robots.txt request, so it was not read. The second is Previdian's own caution. The 22 attempts are a sensor count. By its own wording they do not show that the target was vulnerable or that the attempt succeeded, and the only success any page read reports is a root login on Previdian's own honeypot, as Ostorlab relays it: a machine set up to be attacked.

Previdian's page also lists nine items under a heading for potential proofs of concept, created from 5 November onward, with a notice that they are unverified and may contain malware. This site does not name or link any of them. Ethiack and the CVE record also say public reproduction labs exist, which is why defenders should treat the conditions in the table above as public knowledge.

Where the sources differ

The sources agree on the mechanism and the fixed packages. They differ on the points below, and this site leaves each as a difference.

"Key only" is a label, not a control

The accounts at risk are the ones administrators think of as safe: those with no password because they log in with a key. Alpine says so directly: the * accounts include a key-only user "created with adduser without a password". Ostorlab answers the obvious question, whether key-only logins protect you, with "your own key-only login method does not matter"; what counts is whether PasswordAuthentication is still on and whether a * account exists. A label such as key only, or locked, describes how people log in. It is not a setting that tells sshd to refuse a password. Only PasswordAuthentication no does that, and Alpine says either that or the update closes the hole.

The second label is the version. A package that reads 9.9_p2-r1 looks older than 10.6p2 and is the fixed package for Alpine 3.21. A version number is evidence of a build only if it is read together with the package revision.

Beyond Alpine, and what no source establishes

The CVE record describes the flaw as sshd in OpenSSH before 10.6p2 on Linux, when musl is used without PAM, and gives Alpine Linux as an example of a platform. Ethiack says "Other musl systems, such as OpenWrt or Buildroot images, may also be exposed if they meet the conditions above", and Ostorlab names OpenWrt, Buildroot and Yocto only to tell readers to check the vendor's package. No page read says that any system other than Alpine ships the vulnerable build. That remains unestablished.

Also not established by any source read: who is exploiting the flaw, how many hosts were accessed, which configuration was hit, what CISA's evidence is, and whether the activity Previdian counts reached a real victim. The CVSS score is not in dispute: every source that prints one prints MITRE's 8.1. That score covers the bug; it does not say how likely any given host is to be reached, and Alpine's own conditions do the real sorting.

What to do, in order

Alpine's own instructions come first, marked Alpine. Items marked this site's suggestion are not from a primary source.

Technical details

The artifacts below are the ones the sources print. Each block is attributed to the source that published it and copied from the saved page. Nothing here is exploit code: the sources print no attack tool, and this site prints none. The two fields that carry the trigger are the password length range already given above and the account conditions in the table.

The update command Alpine prints. Run it as root on an Alpine host. It upgrades all packages from the repositories, and it does not restart sshd.

apk upgrade -U -a

The restart Alpine says is required after the upgrade.

rc-service sshd restart

Alpine's workaround for hosts that cannot update. Alpine says to run these as root, that the drop-in directory is read from Alpine 3.19 onward, that the sed command changes yes to no on every PasswordAuthentication line, including inside Match blocks, adds a line at the top and saves the original as a backup file. The last command should print passwordauthentication no. To undo, Alpine says to delete the drop-in file and copy the backup over the configuration.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Checks Ostorlab prints for whether a host meets the conditions: the package, whether this sshd uses PAM, whether passwords are on, which accounts have * and which have a SHA-256 or SHA-512 hash. Ethiack prints the same two awk lines without sudo. If the first awk prints an account, the second prints another, and passwords are on, the conditions in Alpine's table are met. Reading /etc/shadow needs root.

# Alpine: the installed OpenSSH packages and versions
apk info -v openssh-server openssh-server-pam 2>/dev/null

# Whether this sshd uses PAM (no means the vulnerable build on Alpine)
sshd -T 2>/dev/null | grep -i '^usepam'

# Whether password authentication is on
sshd -T 2>/dev/null | grep -i '^passwordauthentication'

# Accounts whose shadow password field is exactly *
sudo awk -F: '$2=="*"{print $1}' /etc/shadow

# Whether any local account has a SHA-256 or SHA-512 hash
sudo awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

The log check Ostorlab prints. Alpine's advisory says to look in /var/log/messages for the same kind of line. Ostorlab warns that a hit is a lead and not proof, since an account with a real hash can also produce an Accepted password line, and that a successful login may have been deleted.

# Alpine and other syslog-based systems
sudo grep -i "Accepted password" /var/log/messages

# Compare the account name with the * accounts on the host
sudo awk -F: '$2=="*"{print $1}' /etc/shadow

The change that fixes the flaw in sshd, as Ostorlab prints it from OpenSSH's commit: a stored hash shorter than four characters can no longer match, so a one character * field fails even when musl returns *. This site did not open the commit itself; it is Ostorlab's rendering of the OpenSSH change.

+#define MIN_PASSWORD_HASH_LEN  4
 #define MAX_PASSWORD_LEN   1024
@@
-   return encrypted_password != NULL &&
+   ret = encrypted_password != NULL &&
+       strlen(pw_password) >= MIN_PASSWORD_HASH_LEN &&
        strcmp(encrypted_password, pw_password) == 0;
+   freezero(pw_password, strlen(pw_password));
+   return ret;

The CVE record's fields for this flaw. The layout is this site's; every value is as printed in the record. It is the only place the CISA SSVC entry appears, with its own stamp and update time.

cveMetadata.cveId: CVE-2026-123158
cveMetadata.assignerShortName: mitre
cveMetadata.dateReserved: 2026-11-05T15:46:25.881Z
cveMetadata.datePublished: 2026-11-05T15:46:26.488Z
cveMetadata.dateUpdated: 2026-11-10T04:55:54.758Z
affected: vendor OpenBSD, product OpenSSH, platforms Linux, version 0 lessThan 10.6p2
description: sshd in OpenSSH before 10.6p2 on Linux, when musl libc is used without PAM, lacks a workaround for a password authentication bypass (related to misinterpretation of whether a string is intended to be a password hash). For some configurations of accounts, any password between 256 and 1024 characters succeeds. An example of a platform using musl libc without PAM is Alpine Linux.
cvssV3_1 (assigned by mitre): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, baseScore 8.1, HIGH
problemTypes: CWE-394 Unexpected Status Code or Return Value
CISA-ADP ssvc (role CISA Coordinator, timestamp 2026-11-05T00:00:00+00:00): Exploitation active, Automatable no, Technical Impact total
CISA-ADP kev: dateAdded 2026-11-09
CISA-ADP providerMetadata.dateUpdated: 2026-11-10T04:55:54.758Z

The KEV entry's fields, as printed in the feed's own entry. The notes field is left out: it links Alpine's advisory, the OpenSSH commit, two CISA directive pages and NVD. This site did not read BOD 26-04, which the entry cites, so it does not say what that directive requires.

cveID: CVE-2026-123158
vendorProject: OpenBSD
product: OpenSSH
vulnerabilityName: OpenBSD OpenSSH Unexpected Status Code or Return Value Vulnerability
dateAdded: 2026-11-09
shortDescription: OpenBSD OpenSSH on Linux contains an unexpected status code or return value vulnerability that could allow for authentication bypass.
requiredAction: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
dueDate: 2026-11-12
knownRansomwareCampaignUse: Unknown
forensicTriage: Yes
cwes: CWE-394

NVD's record, which shows MITRE's score as a secondary score and carries CISA's SSVC entry and the KEV dates.

sourceIdentifier: cve@mitre.org
published: 2026-11-05T16:17:47.110
lastModified: 2026-11-10T05:17:58.923
vulnStatus: Modified
cvssMetricV31 source: cve@mitre.org, type Secondary, baseScore 8.1
ssvcV203 source: 134c704f-9b21-4f2e-91b3-4a467353bcc0, exploitation active
cisaExploitAdd: 2026-11-09
cisaActionDue: 2026-11-12
configurations: openssh versionEndExcluding 10.6; openssh 10.6 (no patch level); openssh 10.6 p1
configurations: alpine_linux, vulnerable false, versionEndExcluding 3.21.10; 3.22.0 to before 3.22.8; 3.23.0 to before 3.23.8; 3.24.0 to before 3.24.4

Indicators. The sources print very little. Ethiack says "No network IoCs have been published." Ostorlab prints one address from Previdian's honeypot report, defanged here as Ostorlab prints it: eight attempts, geolocated to Japan by Ostorlab's account, with sessions that ran id, uname and hostname over non-interactive connections. Ostorlab says to treat a match as a lead, not proof, because an address can be a relay. Previdian's own page reads on 10 November did not print any address; it shows attacker addresses only to paying accounts.

89.116.89[.]18

The question the listing leaves open

CISA says this flaw is being exploited and gives federal agencies until 12 November. It does not say who is exploiting it, which systems were hit, or how many were logged into. So the question is not whether the listing is credible. It is whether you can answer from your own logs what CISA has not published: since 5 November, did any Alpine host accept a password for an account that has none?

Key facts