GreyNoise sensor observations November 7, 2026, tracking page updated November 9, 2026; OpenSSH 10.6p2 released November 5, 2026
The Sensors Caught It Working: the OpenSSH musl Bypass Moved From Disclosure to Observed Exploitation in Two Days
The November 6 edition closed this story with a patch and no exploitation. That second half no longer holds. GreyNoise records its first successful exploitation of the OpenSSH musl password bypass, CVE-2026-123158, against an instrumented vulnerable sensor at 00:46:51 UTC on November 7, two days after OpenSSH released the 10.6p2 fix, with shell command execution as the success test; its tracking page, updated at 00:10 UTC on November 9, showed 16 confirmed post-exploitation activity chains. Precision matters here: sensor evidence proves the exploit works in the wild against a host built to be vulnerable; it is not a count of compromised production systems, and as of November 8 none of OpenSSH, Alpine, Ars Technica or iThome had reported a production case, while the Hong Kong response team bulletin noted a public proof of concept. The scope conditions remain narrow and checkable, and they are the whole triage. The flaw applies to portable OpenSSH before 10.6p2 on Linux built with the musl C library where password checking does not go through PAM: password authentication enabled, a reachable account whose password field is the single character that marks no password set, and another local account holding a sha256 or sha512 password hash whose salt the server borrows. Send that account a password between 257 and 1,024 bytes and musl returns the same marker as its error value, and the comparison passes. Mainstream glibc distributions are outside the scope on the OpenSSH maintainer and response team statements, and Red Hat says its builds are not affected because they use glibc and PAM; that conclusion belongs to those builds and does not transfer to a musl container or appliance sitting beside them. The fix is upstream 10.6p2 or the Alpine branch backport for your release, and the package update only counts once sshd has been restarted. The dated FIRST forecast for the flaw stood at 1.014 percent on November 8, a population estimate that the observed sensor exploitation now outweighs for any host meeting the conditions.
Executives
The status change is the story: a bypass that was theoretical on Thursday was demonstrated working against a live sensor on Saturday, and exploit code is public. The population that matters is not every SSH server; it is the subset running OpenSSH on musl without PAM, which in practice means Alpine-based systems, container images that run their own SSH server, and embedded devices, exactly the assets least likely to sit in a tidy inventory. Ask for that subset by name, with patch and restart evidence for each, and treat any answer built on the distribution fleet as a whole as no answer at all.
CIO / CISO
Triage by configuration, not by product name. A host is in scope only when all of these hold: musl build, no PAM password checking, password authentication on, an account with the no-password marker in its password field, and a second account with a sha256 or sha512 hash. Alpine own advisory conditions add the practical trap: older official cloud images carry an alpine account with that marker and passwordless privilege elevation, safe on first boot and exposed the moment any account gets a password. Sequence the fix as patch, restart, verify, and check the login logs for an accepted password event on an account that has no password; the Alpine advisory treats an unexplained one as a compromise indicator.
Engineers
Apply the branch-correct package rather than chasing the upstream version number: Alpine backports carry older version strings, for example the edge branch fixed package is 10.6_p2-r0 while branch 3.24 is 10.3_p1-r2 and 3.22 is 10.0_p1-r11, and every supported and several unsupported branches have one. Restart sshd after updating and record the running daemon, not only the package. If you must stage the change, disabling password authentication closes the flaw, but verify key access works and keep the current session open until a fresh login succeeds. Then run the log check the advisory prescribes, looking for accepted password logins on marker accounts across the exposure window.
Everyone (non-IT)
For home users this is mostly a nothing-to-do item: ordinary Debian, Ubuntu and Red Hat family systems, including a Raspberry Pi running its standard system, are outside the conditions described. If you run Alpine Linux yourself, or a home server or device built on it with SSH password logins turned on, update the openssh package and restart the service, or turn password logins off and use keys. The check takes minutes and the conditions are exact, so there is no reason to guess.