eMudhra’s CA keys were the numbers 4 to 237: Obol patches Charon, crypto bots and servers need updates

Update, 22 October 2026, 05:30 UTC: Obol, whose Charon software runs distributed validators on Ethereum, published Charon v1.11.2 on 21 October at about 15:10 UTC and calls it “a required release for all Operators”. The patch moves Charon to Go 1.27.3, which carries the fix for CVE-2026-111943, the identifier of the eMudhra case, and distrusts the emSign ECC Root CA – G3 and AAA Certificate Services roots inside its Docker image. The release ties the fix to the eMudhra certificates and describes no compromise of Obol’s own keys. Crypto Briefing and The Defiant put the ether in Obol’s mainnet clusters at 422,862 ETH in Obol’s latest daily snapshot, and Crypto Briefing writes that nothing in the disclosure says any funds were affected. Details in the new section below.

Eight private keys used by intermediate certificate authorities of eMudhra, an Indian company that issues web certificates, were tiny numbers: the smallest was 4, the largest 237. Mozilla confirmed the weakness in an incident report it opened on 18 October and made public on 20 October 2026, the day researcher Scott Helme published the values. With these keys, anyone could sign a trusted-looking HTTPS certificate for any domain. Firefox, Chrome, Safari and Edge blocked the eMudhra certificate chains between 17 and 20 October. Software that runs outside a browser, such as curl, Python and Node scripts, Go services and Electron apps, keeps trusting them until its certificate list is updated.

For crypto users, that second group is the one that matters. Exchange trading bots, wallet back-ends, node tooling and desktop wallets built on Electron all make HTTPS calls without a browser. No attack using the keys has been reported, and no crypto loss is known. Seed phrases, hardware wallets and the secp256k1 keys that control bitcoin and ether are not involved: this is a software-update story, not a crypto hack.

eMudhra certificate keys: what broke and what did not

A certificate authority (CA) vouches that a website is who it claims to be, and root CAs delegate daily signing to intermediates. The eight broken keys belong to such intermediates, not to websites. Each key backs two CA certificates, one under eMudhra’s own root and one cross-signed by Sectigo, so 16 in total, according to the Mozilla bug and Helme. Six serve TLS, two code signing. Sectigo noted in the bug that its root behind the cross-signatures had already left the Chrome and Mozilla stores some time ago but is still trusted by Microsoft and Apple.

The encryption itself was never weak. Cloudflare, which had to patch its own client software, put it this way: “This work addresses certificate-based authentication, not a weakness in TLS’s encryption algorithms.” The risk is impersonation. An attacker holding a key could mint a certificate for, say, an exchange API, but would still need to sit between the victim and the real server, on hostile Wi-Fi, a compromised router or a rogue network, to use it. That makes it a man-in-the-middle tool, not a cheap way to run a phishing site that people reach by clicking a link.

Private keys between 4 and 237, recovered in under a second

The keys are elliptic-curve keys on the NIST P-384 curve. On that curve, a private key is a number and the public key is that number multiplied by a fixed starting point. A properly generated P-384 key is drawn from a space of about 10¹¹⁵ values. Mozilla’s Dennis Jackson wrote in the bug that the eMudhra keys were “effectively all-zeroes apart from the last byte”, which leaves at most 255 candidates. An attacker only has to compute 1 times the point, 2 times, 3 times, and compare each result with the public key printed in the certificate.

Helme did exactly that. “I recovered all of them from their public certificates on my laptop just now, and it took less than a second,” he wrote in his write-up. An update to the same post adds that “Claude was able to recover the private keys with a single prompt”. Jackson reported something similar in the bug: local AI agents recovered a key at the first attempt from a one-line prompt. Here are the values Helme published:

eMudhra has not published a statement of its own; its account sits in comments on the Mozilla bug. The company blames a flaw in its key generation ceremony script, which created a second, weaker key pair in the hardware security module. Because the key labels were similar, the weak keys were used by mistake for the certificate requests. eMudhra says it is still assessing the code, so the root-cause analysis is not finished. It says the RSA keys made the same day went through a different path and are not affected, and that its A and A-1 ECDSA series were made on Entrust HSMs for use in India only. Mozilla has not confirmed either point: Jackson wrote that he could not break the A and A-1 keys despite much more effort, and had not yet started on the RSA keys.

From an April 2025 key ceremony to a browser block in under three hours

Helme counts a 17-month window: “That’s a 17 month window and there is no way to know whether someone did.” The main dates, in UTC, from the Mozilla bug, Mozilla’s blog, Cloudflare and Helme:

• On 30 April 2025, the affected intermediates were generated at a single eMudhra key ceremony; Sectigo cross-signed them in May 2025, according to Helme.
• On Saturday 17 October 2026, a researcher reported the break to browser makers, and Mozilla received the report at 20:06.
• By 22:59 the same evening, Mozilla had pushed the distrust to Firefox through its OneCRL list, “in less than 3 hours after we received the report,” its security blog says; Chrome blocked the intermediates that evening too.
• On 18 October, between 09:24 and 09:38, eMudhra revoked the eight certificates, according to the bug.
• On 19 October, Sectigo finished revoking its cross-signatures, Apple blocked the chains, Mozilla began alerting other trust-store operators and Cloudflare learned of the issue at about 17:00.
• On 20 October, Microsoft applied its block, Mozilla shipped Firefox 158.0.1, Firefox ESR 115.43.1 and 153.5.1 and NSS 3.131.1, and the bug became public.

On 20 October Mozilla also decided on the emergency removal of the root above them, “emSign ECC Root CA – G3”, and Chrome said in the bug it would take a similar path. NSS 3.131.1 drops that root from the trusted list. eMudhra estimates about 30,000 customer certificates now need to move to another chain, about 97% of them issued through the automated ACME protocol.

Browsers check Certificate Transparency; curl, Python and Node do not

Browser users were shielded even before the blocks. Chrome, Firefox and Safari require certificates to appear in public Certificate Transparency (CT) logs, and none from these intermediates has shown up there since April 2025, Jackson’s advisory notes.

Most other software works differently. It reads a certificate bundle stored on disk, rarely checks revocation and does not look at CT logs. Jackson’s advisory site says it plainly: “many clients outside of the browser ecosystem do not enforce Certificate Transparency.”

Helme tested the gap with a local server presenting a certificate for api.stripe.com chained to one of the broken intermediates. With default settings, curl reported “SSL certificate verify ok”, Python completed the handshake and Node returned “authorized: true”. That held on every Linux and macOS machine he tried. On Windows, the system accepted the chain unless revocation checking was switched on.

Revocation does not help those clients. “So the fact that eMudhra and Sectigo have revoked these intermediates doesn’t help them at all,” Helme wrote, because many programs never ask whether a certificate was revoked. Only a new certificate bundle, or a library that ships its own updated list, removes the trust. Cloudflare says: “Our security review has not identified active exploitation of this issue on Cloudflare services.”

Why crypto bots, wallet back-ends and Electron apps are exposed

CoinDesk made the crypto link on 21 October: exchange bots, trading scripts and wallet back-ends often run on Python, Node or Go. In theory, a forged certificate for an exchange API would let an attacker on the same network read or alter a bot’s traffic. Helme points out that server-to-server API calls carry secrets in their headers; for a trading bot, that means its exchange API keys. That is a scenario, not an incident. Mudit Gupta, chief technology officer of Polygon Labs, told CoinDesk: “This is not a crypto-specific issue.” He called it a generic man-in-the-middle risk, aimed mostly at people running old or unpatched software, and said crypto users who keep wallets, trading tools and devices updated face lower risk.

The people concerned are those who run code: bot and node operators, teams with self-hosted wallets or explorers, and users of Electron desktop wallets, which bundle their own trust list. We found no statement from any exchange or wallet provider saying it was affected, and none saying it was safe. One concrete case now comes from staking infrastructure: on 21 October Obol shipped a required Charon release for its distributed-validator operators, covered in the next section.

The keys in this story have nothing to do with the keys that hold coins. A private key for a bitcoin or ether address lives on the secp256k1 curve and is generated by your wallet, and your seed phrase never touches a certificate authority. Nothing here requires moving funds.

Obol’s Charon v1.11.2: what distributed-validator operators should do

Charon is the middleware that lets several operators run one Ethereum validator together, a set-up known as distributed validator technology (DVT). Its v1.11.2 changelog has a single line: a bump to Go 1.27.3 and the distrust of the emSign and AAA roots in the image. The change was merged on the main branch at 14:00 UTC on 21 October (pull request #4796) and backported to the v1.11 branch at 14:54 UTC (#4799), which moved Charon from Go 1.26.6 to 1.27.3 for the crypto/x509 fix. The second part is the container case described above: the Debian-based runtime image marks the two roots as distrusted in its certificate configuration, for wget and other non-Go tools, until Debian’s own ca-certificates package drops them.

The stake involved is large. Crypto Briefing and The Defiant report 422,862 ETH in Obol’s mainnet cluster balances, citing Obol’s latest daily snapshot without giving its date. At ETH near $2,444 at 04:37 UTC on 22 October, that is about $1.03 billion, by Coindaro’s arithmetic. It is the amount staked through Obol clusters, not an amount at risk. Crypto Briefing writes that “nothing in the disclosure says any funds were affected.” No slashing, downtime or loss has been reported.

Obol has published no security advisory or blog post on the case; the release note is its only statement. It does not say how Charon uses the affected roots or what an attacker with a forged certificate could do against a cluster. Validator keys in Obol clusters are split between operators by a distributed key generation and have nothing to do with TLS certificates, but that is the general design, not something Obol has said about this case.

What operators can do, going by the release and its pull requests:

• Upgrade every Charon node of the cluster to v1.11.2 or newer; Obol marks it required for all operators and says it is backwards compatible with Charon v1.0 and later.
• If you run Charon from the Docker image, pull the v1.11.2 image and recreate the container, since the Go binary and the certificate store both live in the image.
• If you build Charon yourself, build with the Go 1.27.3 toolchain and check the certificate bundle of your own runtime image.
• Our own advice, not Obol’s: update the beacon node, validator client and monitoring containers that sit beside Charon as well, because each one reads its own certificate bundle.
• Plan the next upgrade: v1.11.2 is not ready for Gloas, the consensus half of Glamsterdam. On Hoodi, all nodes of a cluster must run v2.0.0-rc2 or newer, which includes the same Go fix, before the fork on 26 October 2026 at 17:42:48 UTC; mainnet operators should wait for a full v2.0.0, Obol says.

Our page on the Glamsterdam upgrade on the Hoodi testnet follows that date.

What to update today, and a one-line curl test

Jackson’s advisory keeps a table of fixed versions. The main ones as listed on 21 October, plus Cloudflare’s tunnel client from Cloudflare’s own post and Obol’s Charon from its release notes:

The practical steps for anyone running bots or crypto infrastructure:

• Update the operating system’s ca-certificates package on every server, VPS and laptop that runs your scripts.
• Upgrade certifi in each Python virtual environment, since requests and many exchange SDKs read certifi rather than the system store.
• Rebuild container images, which freeze the certificate bundle at build time, then redeploy them.
• Update Electron-based desktop wallets and tools once their makers ship a release on a patched Electron.
• Never “fix” a certificate error by turning verification off; Cloudflare warns against exactly that.

Then test. Jackson runs hosts that present certificates from the broken chains. From the machine and the environment your bot actually uses, run:

curl https://dv-g3b-emudhra.we-have-a-problem.com/

A certificate error is the result you want: it means the client no longer trusts the compromised intermediates. A second host, dv-g3b-aaa-emudhra.we-have-a-problem.com, checks the Sectigo cross-signed route. If curl loads the page, the bundle it reads is still old. Mac users take note: Jackson says macOS itself blocks the intermediates, but the built-in /usr/bin/curl checks against /etc/ssl/cert.pem, which has not been updated. Cloudflare adds one caution: check through the application’s own TLS path, because a Node or Electron app may not use the same bundle as curl.

Not the same problem as the NIST curve seed story

Four days earlier, we reported that Claude traced the published seeds of NIST curves to a 1997 clock, a story that also involved P-384. The two are unrelated. That piece was about how the curve parameters were chosen, and Bitcoin and Ethereum use secp256k1, which has no such seed. In the eMudhra case the curve works as designed; the company picked private keys that were tiny numbers.

Tiny key spaces have emptied crypto wallets before

The comparison below is Coindaro’s, not Mozilla’s or Helme’s, and no source we read draws it. eMudhra belongs to a family of failures crypto has met several times: a secret that looks valid but comes from a space small enough to search.

In the Milk Sad case, disclosed on 8 August 2023, the Libbitcoin Explorer “bx seed” command drew wallet seeds from about 32 bits of clock-based entropy, and the main theft on 12 July 2023 took about 29.65 BTC (the Libbitcoin team disputes that it was a bug). In September 2022, 1inch showed that the Profanity vanity-address tool seeded Ethereum keys from a 32-bit value, about 4 billion starting points; experts cited by The Block tied Wintermute’s $160 million loss that month to a Profanity address, which Wintermute’s CEO put down to internal human error.

On 19 October, the day before the eMudhra bug went public, we reported that Qubic halted its chain after weak wallet seeds let an attacker drain 1,404 wallets. The difference is the outcome. In those cases coins were taken. With eMudhra, the weak secrets guarded certificates, and no theft is known.

What is still unknown

Whether anyone used the keys during the 17 months cannot be settled, since clients that skip CT checks leave no trace. Whether any real website certificate was issued from the broken intermediates rests on eMudhra’s word. It told the bug that only one of them, EM DV TLS CA – G3C, was ever put into production and that it issued no end-entity certificates; no one has checked that independently.

eMudhra’s root-cause analysis is still open, and Mozilla has not verified its claim about the other series. The next items to watch are the Node.js and Bun releases with an updated trust list, the FreeBSD package, and the migration of the roughly 30,000 certificates away from the removed emSign root.