On October 17, 2026 a researcher showed that the private keys of eight eMudhra intermediate certificate authorities can be computed from their public certificates. One key is the number 4. The rest are whole numbers below 256. Anyone can sign a certificate for any hostname with them, offline, with no log entry anywhere.
Browsers, phones and current operating systems blocked the certificates within days. A connected medical device did not. Its trust store is compiled into firmware, often in three to five places, and none of them changes without a device update. Each weak intermediate was also cross-signed by Sectigo under AAA Certificate Services, a root that has shipped in Linux, Java and OpenSSL bundles since 2004. A device that never trusted eMudhra still accepts the forged chain.
Until the trust store changes, every TLS connection the device makes can be intercepted by anyone on the network path. For a device that never gets the update, that is the rest of its service life. ELTON classifies this as a forever vulnerability and rates it Critical for any connected device that trusts a public CA bundle, does not enforce revocation and does not pin its server's key.
eMudhra is a certificate authority whose roots sit in the Mozilla, Chrome, Apple and Microsoft trust programs. During a key generation ceremony on April 30, 2025, a flaw in a key wrap and unwrap step produced a weak set of keys for 24 subordinate CAs, and the weak set is what reached the root stores. Eight intermediates carry the weak keys: six for TLS and two for code signing. Each also exists as a second certificate with the same public key, cross-signed by Sectigo under AAA Certificate Services.
| Intermediate | Type | Operator |
|---|---|---|
| EM DV TLS CA - G3B | TLS, domain validated | eMudhra BV |
| EM DV TLS CA - G3C | TLS, domain validated | eMudhra Inc |
| EM OV TLS CA - G3B | TLS, organization validated | eMudhra BV |
| EM OV TLS CA - G3C | TLS, organization validated | eMudhra Inc |
| EM EV TLS CA - G3B | TLS, extended validation | eMudhra BV |
| EM EV TLS CA - G3C | TLS, extended validation | eMudhra Inc |
| EM OV CS CA - G3B | Code signing | eMudhra BV |
| EM OV CS CA - G3C | Code signing | eMudhra Inc |
The keys are P-384 elliptic curve keys. A proper P-384 private key is a random number about 115 digits long. These are whole numbers smaller than 256, three to eight bits of entropy by Qualys's count. Recovering one means trying at most 256 values against the public key in the certificate. Mozilla had all eight within two hours of the report. Scott Helme had them in under a second on a laptop. The keys have since been published.
The CA system handles a bad certificate by revoking it and publishing that fact on a certificate revocation list or an OCSP responder. Browsers consult those through their own fast channels, which is how Chrome and Firefox were protected the same evening. An embedded TLS client almost never checks revocation. It has no reliable clock, no guaranteed path to the responder, and a soft-fail default that accepts the connection when the check cannot complete. To a client that does not check, a revoked certificate and a valid one look identical.
Sectigo cross-signed each weak intermediate under AAA Certificate Services, one of the oldest and most widely distributed roots in existence. It is in the ca-certificates bundles embedded Linux has shipped for twenty years, in Java's cacerts, in curl's bundle and in most vendor OpenSSL bundles. A forged leaf, the cross-signed intermediate and the AAA root form a chain that validates on a device built in 2012. The device has never trusted eMudhra. It does not need to.
From that point the device is talking to the attacker. Telemetry, configuration, firmware update manifests, clinician portals, patient data in transit: whatever the connection carried, the attacker now reads and can alter. The traffic is still encrypted, to the wrong party. For the device, the connection is plaintext.
A device is affected when any TLS client on it meets three conditions together:
The decision is made per TLS implementation, not per device. A typical connected product has three to five separate validation environments, and they do not update together.
| Component | Potential trust store | Changes without a device update? |
|---|---|---|
| Embedded Linux OS | /etc/ssl/certs and the ca-certificates bundle | Usually not |
| OpenSSL-based application | The OS bundle, or a custom CA file shipped with the app | Depends on configuration |
| Java application | cacerts in the JRE | Usually needs an explicit update |
| Embedded browser or WebView | OS-managed or browser-managed store | Platform-dependent |
| Firmware or proprietary TLS stack | Roots or public keys embedded in the binary | Needs a firmware update |
The same test applies to companion applications. An app built on the platform networking stack inherited Apple's block on October 19 and Android's the same day. An app that bundles its own OpenSSL or Java trust store, common in medical for FIPS reasons, is exposed until it is rebuilt and redeployed.
Outside the exposure: a device that validates only against a private manufacturer CA with the public bundle stripped from every TLS implementation, a client that pins the server's public key on every implementation, and a device with no outbound TLS at all. Most fielded devices are not in that group. The public bundle comes with the operating system, and nobody removes it.
What an attacker needs: a position on the network path between the device and its server (a hospital network segment, the Wi-Fi a home-use device joins, a service laptop, an upstream provider), the published keys, and the hostname the device connects to, which the device announces in DNS and in the TLS handshake. No contact with the manufacturer, no certificate issued through any CA, no Certificate Transparency entry, and nothing visible at the real server.
What it yields: read and write access to everything the connection carries. On a device that fetches firmware over that connection and does not separately verify the image signature, the attacker can offer it a firmware image. On a device that takes configuration or commands from its cloud, the attacker can send them.
Why it is permanent: the keys cannot be withdrawn, nothing on the server side changes what the client is willing to believe, and the only control that changes the outcome lives in device firmware.
Section 524B requires a plan to monitor, identify and address postmarket vulnerabilities, and patches as soon as possible, out of cycle, for critical vulnerabilities that could cause uncontrolled risks. This is that case: a critical vulnerability, publicly exploitable, affecting the confidentiality and integrity of every connection the device makes, with firmware delivery as a plausible consequence.
Premarket: the CA bundle is an SBOM component with a published vulnerability (CVE-2026-111943, CVE-2026-111944), distribution advisories and a Red Hat bulletin rated Important. A submission whose bundle still trusts the affected roots, whose TLS clients do not enforce revocation, and whose connections are not pinned is presenting a known, publicly exploitable flaw inside its own secure communication claim. ELTON's position: expect that submission to draw a cybersecurity deficiency, and fix it before sending it in.
Postmarket: the 524B plan now has to show the exposure assessment per product, the patch schedule, and for products that will not be patched, the risk acceptance and the compensating controls communicated to customers. A statement that the manufacturer never bought a certificate from eMudhra does not answer the question.
Removing the roots fixes this event. Pinning closes the class.
ELTON tests the exposure per outbound connection, on the real device, and evidences the result for the 524B plan or the submission:
The result is a disposition per connection with the evidence attached: exposed, mitigated, or not affected. The test takes minutes per connection. See exploitability verification and the full analysis in the whitepaper.
Find out which of your connections accept the forged chain.Per connection, on the real device, in minutes. Evidence packaged for the 524B plan.
Eight eMudhra intermediate certificate authorities were issued with private keys that are small whole numbers, one of them the number 4, so anyone can compute them from the public certificates and sign a certificate for any hostname. Browsers and phones blocked the certificates within days. A medical device carries its trust store in firmware, so it keeps accepting the forged chain until a device update changes that store. For a device that never gets the update, the exposure lasts its whole service life, which is why ELTON calls it a forever vulnerability. It is tracked as CVE-2026-111943 and CVE-2026-111944 and as ELTON exploitability notification ELTON-EN-2026-001.
Usually yes. Each weak intermediate was also cross-signed by Sectigo under AAA Certificate Services, a root that has shipped in Linux ca-certificates bundles, Java cacerts, curl and most vendor OpenSSL bundles since 2004. A forged leaf, the cross-signed intermediate and that root form a chain that validates on a device that has never heard of eMudhra. What matters is what each TLS client on the device trusts, not which CA the manufacturer bought certificates from.
Not for an embedded device. Revocation only protects a client that checks a revocation list or an OCSP responder, and embedded TLS clients almost never do: they lack a reliable clock, a guaranteed path to the responder, and most soft-fail by accepting the connection when the check cannot complete. The keys themselves cannot be withdrawn, because they are derivable from certificates that will exist in public archives indefinitely.
Remove the affected roots from every trust store on the device and its companion app, and pin the server's public key on every TLS implementation so that no certificate authority, weak or compromised, can speak for the manufacturer's server. That is a firmware change, so it goes through verification and release. Section 524B calls for it as soon as possible, out of cycle. For products that will not be patched, the postmarket plan needs the risk acceptance and the compensating controls communicated to customers.
Per outbound connection, on the real device. ELTON enumerates every TLS implementation and what it trusts, checks each store for the affected roots, presents a forged chain for the device's real hostname through the cross-signed intermediate, records whether the client accepts it, and tests revocation and pinning behaviour. The result is a disposition per connection with the evidence attached, in minutes per connection, packaged for the 524B plan or the submission.