A Certificate Authority's Private Key Was 4. Your Lightning Node's Trust List Is Compiled Into the Binary

What Happened

On Saturday, October 17, a researcher reported to Apple, Google, Microsoft, Mozilla, and the Indian certificate authority (CA) eMudhra that the private keys behind 8 of its intermediate certificates had been compromised. Nothing was stolen: the keys were so small that anyone could compute them from the public certificates.

Security researcher Scott Helme wrote that he recovered all 8 on his laptop in under a second, and that P-384 keys meant to carry about 384 bits of randomness carried between 3 and 8. The values were 4, 56, 66, 115, 155, 156, 230, and 237. Chrome's root program logged the report at 18:05 UTC and blocked the certificates that evening; Mozilla, which got it at 20:06 UTC, had them in Firefox's revocation list within about 3 hours (its bug 2083449 is the public record).

Apple followed on Monday, October 19, and Microsoft on Tuesday, October 20.

eMudhra's statement, last updated Wednesday, October 21, says the 8 certificates (6 for TLS, the protocol behind HTTPS, and 2 for code signing) came out of an April 2025 key ceremony in which a wrap-and-unwrap step produced a second, weak set of keys beside the intended ones, and the weak set is what got published.

It says its root keys are unaffected, that most of the intermediates never entered production, that it has found no certificates issued from them to end users, and that it has 'not yet confirmed the exact root cause.' It revoked the 8 on Sunday, October 18; Sectigo, which had cross-signed the same keys under its AAA Certificate Services root, revoked its copies on Monday.

Google says no certificate chaining to the 6 TLS intermediates had been logged to Certificate Transparency, the public log of issued certificates, before the block. Mozilla dropped the root the TLS intermediates chain to, emSign ECC Root CA - G3, on Tuesday, October 20; Chrome drops it on Tuesday, October 27.

The browsers fixed themselves in hours. A node fixes itself only when it is rebuilt, because who it trusts was compiled in, not configured. A certificate authority's private key was 4; the only road from that number to a Lightning node runs through connections the operator chose.

The Block Lives in the Binary, Not the Operating System

The browsers fixed themselves. Software that is not a browser gets the block only when it is rebuilt or its trust store is replaced. On Monday, October 19, the Go project released Go 1.27.3 and 1.26.10 with a single change, tracked as CVE-2026-111943: the crypto/x509 verifier 'will now filter out chains which contain these intermediates, preventing them from being returned to the caller.'

The filter keys on the 8 public keys rather than on a root, and the distinction matters because each key existed in 2 certificates, 1 under eMudhra's own root and 1 cross-signed by Sectigo. Where a trust store trusts Sectigo's AAA Certificate Services for TLS (Debian's system store, which curl, wget, and a Go binary on Linux all read), deleting the eMudhra root changes nothing, as Ulises Gascón's reproducible check and Endor Labs documented this week.

Only revocation checking, which most non-browser clients skip, or a key-based block closes the cross-signed path. Go, Chrome, and Node.js took the key-based route.

Lightning Labs' stack is written in Go, so for its users the fix arrives as a rebuild. btcd v0.27.0 shipped on Wednesday, October 21, 'built with Go 1.27.3.' That night, Eastern time, Lightning Labs published Lightning Terminal v0.17.8 and Taproot Assets v0.8.7, whose notes say the daemons were rebuilt with Go 1.

27.3 'to address CVE-2026-111943' and that 'we recommend that all users upgrade,' and the lnd project tagged v0.21.5-beta.rc1 and v0.20.6-beta.rc1 compiled with the same toolchain. Chief technology officer Olaoluwa Osuntokun told users of lnd, btcd, tapd, and litd to install the new binaries or rebuild with Go 1.

27.3, per KuCoin News's account of his post. An operator who patched a Debian-based host this week and left a 3-week-old lnd binary running has the eMudhra root gone, the key-based block absent, and the Sectigo cross-sign still trusted.

What This Means for You

First, the real size of the risk. Lightning's security does not run on TLS: channel funds sit under Bitcoin script, and peer connections use their own key exchange, not certificates. Neither is touched. lnd checks a public CA's signature only on outbound connections an operator chooses: the external fee estimation URL, which the sample configuration says 'must be set for neutrino on mainnet' with Lightning Labs' own host as the example, and, in Lightning Terminal, the connection to the Loop swap server, which the client verifies with Go's default root store unless an operator pins a certificate file.

An attacker holding one of the 8 keys and sitting on your network path could have impersonated those hosts: feeding a fee rate that makes a channel close overpay, or standing in for the swap server. No such certificate has been seen. A bitcoind-backed lnd node with no fee URL and no Loop had, on the public record, nothing to exploit.

Second, the action, which is the same whatever the size: update the binaries, not just the box. btcd to v0.27.0, Lightning Terminal to v0.17.8, tapd to v0.8.7, and lnd to the candidate if you run candidates or to v0.21.5-beta when it is final (that release also clamps fee rates from an external fee URL to 10,000 sat/vB, a sanity bound that blunts the fee-feed attack on its own).

If you build from source, the toolchain is the fix: the notes name Go 1.27.3 because reproducible builds require verifiers to use the same compiler. Anything else that ships its own trust store (Python's certifi, Node.js, Electron apps, the container images your node runs in) needs its own update; a patched host does not reach inside them.

Third, the limit this exposes. Running your own node takes custodians out of your balance sheet. It does not take the Web's trust anchors out of your software. Your lnd binary carries a judgment, made by a root program you do not sit on, about which certificate authorities to believe, and one of them ran a ceremony in April 2025 that produced the number 4 and published it.

Self-custody already has the answer in its own vocabulary: pin what you can. lnd pins its own RPC certificate so that lncli cannot be fooled by any public CA; Loop accepts a pinned certificate path; btcd's RPC does the same. What stays unpinned is the short list of connections you chose for convenience, and this week showed that the list is a shipped artifact of a compiler release, not a setting you control.

What to Watch

Whether the lnd candidates become v0.21.5-beta and v0.20.6-beta, and whether the Go bump is their only change, is the first checkpoint. Chrome's removal of emSign ECC Root CA - G3 on Tuesday, October 27, will show in the sites that break how much of eMudhra's book was live. eMudhra has said it will re-verify every key ceremony it has run; Mozilla says it is not removing the company's other root, emSign Root CA - G1, for now, and that review decides whether it stays.

If a certificate signed by one of the 8 keys ever surfaces in a Certificate Transparency log or a malware sample, this week's 'no exploitation seen' lines become dated claims. And the count: Coldcard's seed generator in July, Qubic's Math.random seeds last week, now a certificate authority's ceremony.

The weak-randomness failures of 2026 have moved from wallets to the trust root, one layer above where most holders have been looking.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.