DemoMonitor M3 is a fictional bedside patient monitor, built only to show the path. Its firmware is a small Linux image on the musl C library, it keeps OpenSSH open on the ward network for field service, and its key-only service account can become root without a password. The graph is how ELTON reads this notification on a product like it: toggle the entry vector and the preconditions, apply a mitigation, and watch the verdict change. It is the same dependency graph ELTON builds for every product it tests: entry vectors produce conditions, findings require them, and the chain decides which of the four verdicts a finding gets on that device.
SSHole is an authentication bypass in the OpenSSH server, CVE-2026-123158, disclosed on November 5, 2026 and rated 8.1 on CVSS v3.1. On Linux built with the musl C library and without PAM, an attacker who can reach the SSH port logs in to an account that has no password by sending any password between 257 and 1,024 bytes. It takes one connection and it works every time.
The accounts it opens are the ones a team counts as safest: key-only service and deployment accounts, whose password field holds a single asterisk because no password was ever set. Exploitation began less than nine hours after the CVE was published. CISA added it to the Known Exploited Vulnerabilities catalog on November 9, and proof-of-concept code is public.
Medical devices sit inside the affected population. musl is the default C library in Alpine and OpenWrt and a common choice in Yocto and Buildroot images, small firmware rarely includes PAM, and OpenSSH is the usual door for field service. A fielded device keeps the sshd it was built with until a firmware update ships. ELTON rates this High, and Critical on any product where the account an attacker reaches can become root.
Without PAM, sshd checks a password itself. It hashes the attempt with the C library's crypt() function and compares the result with the account's stored password field. When the stored field is too short to hold a salt, sshd borrows the salt of another account and hashes anyway, a 2016 change that closed a timing leak of valid usernames (CVE-2016-6210).
musl's crypt() refuses a password longer than 256 bytes and returns the string * to signal the error. An account with no password stores that same * in its password field. The two strings are equal, so sshd treats the password as correct.
The conditions, from the Alpine Linux advisory:
*: a key-only user, a directory-service user, or root on images that ship it that way.$5$ or $6$ password hash, which supplies the borrowed salt.Fixed release: OpenSSH 10.6p2, published November 5, 2026. The OpenSSH project places the root cause outside sshd and closed it there anyway. Alpine Linux published fixed packages for every branch from 3.16 to edge the same day. Installing the update does not replace the running daemon, so the old binary keeps accepting logins until sshd restarts.
Özgün Kültekin of Wakefield found the flaw with swarms of AI agents, building sshd in every combination and sending about 17,600 unusual login attempts at the builds. Only the musl build without PAM let in logins it should have refused. The OpenSSH release notes say the project now receives a large number of AI-assisted reports and will release more often because of it.
A device is affected when all of these hold:
* as its password field.Where it hides in a medical product:
| Component | Typical SSH use | Who can reach it |
|---|---|---|
| Device firmware | Field service, manufacturing and log retrieval on the Ethernet or Wi-Fi interface | Anyone on the device's network segment |
| Gateway, hub or dock | Remote support and provisioning | The clinical network |
| Vendor appliance or server image | Management access the vendor maintains, often on an Alpine base | Hospital IT network |
| Containers and cloud images | sshd inside an Alpine-based image. Alpine's own cloud images from 3.18.11 through 3.24.3 ship a default user with no password and passwordless root | The internet or a VPN |
Not affected: systems built on glibc, such as Debian, Ubuntu and Fedora; builds that check passwords through PAM; Dropbear; OpenBSD. A device with password logins off is safe, and so is an account locked with ! in its password field.
The SBOM lists OpenSSH and its version. It does not say which C library sshd was linked against, whether PAM was compiled in, what the password setting is, or which accounts hold a *. Those are facts of the build and its configuration, and they decide the exposure.
Finding every affected product across a portfolio is a search on those shared attributes. ELTON runs it on the digital twin it builds for every product during onboarding, before any test runs: a blueprint of the product, deeper than a threat model, with its components, interfaces, software materials and the network each interface listens on. One query across the twins lists every product that answers SSH, the build behind it, and the access ELTON holds to each one. The next sshd flaw is the same query.
Unauthenticated, remote, one connection. The attacker needs the name of an account that has no password, and those names are predictable: a vendor's service account, a deployment user, the default user of a base image. There is no race and no memory corruption, so one attempt is enough.
The CVE record scores attack complexity as high because the configuration has to line up. On a device it lines up at build time, the same way on every unit shipped.
What it yields: a shell as that account. On a device, that is its configuration, its stored data and credentials, the service functions behind the login, and a foothold on the clinical network. OpenSSH's default setting keeps root itself from logging in with a password, so the path to root runs through an account that can elevate without one.
Whether a specific product is exploitable depends on its build and its configuration as shipped, so the answer comes from a login attempt on the device. A version number alone cannot give it.
How ELTON reaches the verdict: the finding is placed in the product's exploit chain with the entry vector and the conditions it needs. The chain above is the one for the example monitor, and it decides whether the finding is directly exploitable, conditionally exploitable, an unexploitable weakness or a mitigated weakness on this device. The method is the dependency graph, and it is why a monitor whose SSH port is closed outside service mode gets a different verdict from the same CVE than one that answers on the ward network.
Section 524B asks for a plan to monitor, identify and address postmarket vulnerabilities, and for patches as soon as possible, out of cycle, for critical vulnerabilities that could cause uncontrolled risks. A remote login bypass in CISA's Known Exploited Vulnerabilities catalog meets that description wherever the port is reachable.
OpenSSH is an SBOM component, so a reviewer can see the version. A submission in review that ships an affected build will be asked for its assessment, and the answer needs the build facts the SBOM leaves out. Settle it before sending the submission in.
Postmarket, the plan needs the exposure assessment per product: which products run sshd, on which C library, with which authentication settings, where the port listens, the test result, and for products not yet updated, the compensating controls communicated to customers.
! in the password field refuses the login outright.Verifying the fix: once the update is built, ELTON's agentic pentesting runs the login again against the whole physical product in the lab: the oversized password against every passwordless account, on the running daemon, with the interim setting where the patch has not shipped. The test case is the one that found the exposure, so the retest is the same case, and the result is evidence that the login is refused on the shipped build. The reach into the physical device is TestLink, the appliance ELTON puts on your bench or in its own lab. Only ELTON has it, and it carries the pipeline from software into the physical product: the models build the test and TestLink runs it on the real device.
Findings on a covered product arrive in days. The agentic pipeline builds the test once and runs it again after the fix. See exploitability verification and the incident response process.
A manufacturer with an affected product sends its customers a disclosure statement: where the exposure sits, the exploit chain, the verdict, the fix and its status, and the test that proves the fix. ELTON builds that statement and the VEX for its customers from platform data. The same statement is available as a blank template to complete by hand, with a finished example, on the disclosure templates page.
Find out which products in your portfolio answer SSH on a musl build.Inventory from the digital twin, the login attempted on the real device, disposition per product.
SSHole is the name for CVE-2026-123158, an authentication bypass in the OpenSSH server disclosed on November 5, 2026 and rated 8.1 on CVSS v3.1. On Linux built with the musl C library and without PAM, an attacker who can reach the SSH port logs in to an account that has no password by sending any password between 257 and 1,024 bytes. ELTON tracks it as exploitability notification ELTON-EN-2026-003.
OpenSSH 10.6p2, released November 5, 2026. Alpine Linux published fixed packages for every branch from 3.16 to edge the same day, and other distributions carry their own backports. The update does not replace the running daemon, so sshd has to be restarted before the fix takes effect.
Small embedded Linux images are often built on musl, rarely include PAM, and keep OpenSSH open for field service. Their service accounts are usually key-only, which means the password field holds the single asterisk this flaw matches. A device like that, reachable on a hospital network, gives a shell to anyone who knows the account name, and fielded firmware keeps the vulnerable sshd until an update ships.
Turn password logins off with PasswordAuthentication no and restart sshd, which closes the hole on its own. Close the SSH port outside service mode or move it to a service VLAN, lock accounts that never log in, and remove passwordless root from accounts reachable over SSH. Then check the logs for an accepted password on an account that has none.
The SBOM lists OpenSSH and its version, but the exposure depends on build facts it does not carry: the C library, PAM, the password setting and the accounts. ELTON reads those from each product's digital twin, then attempts the login on the real device through TestLink and records the result. Each product gets one of four verdicts with the evidence attached.