Understanding the eMudhra Key Compromise

by:

in Node.js on Oct 23 2026

Node.js

Rafael Gonzaga
Principal Open Source Engineer at NodeSource & Node.js TSC

Note: Our team (and everyone across the ecosystem) has had quite the week. We have been working around the clock to patch Node.js and our N|Solid Runtime to respond to this major compromise. We will share that story separately, but wanted to share some key details about the attack, why it happened, and what you should do.

TL;DR

One of the companies the whole web trusts to vouch for websites had a secret signing key equal to the number 4, so anyone could have faked a trusted HTTPS site until browsers blocked it on October 17–20, 2026.

Who: eMudhra, an Indian certificate authority (CA) trusted by Chrome, Firefox, Apple and Microsoft.
What: the private keys of eight eMudhra intermediate CA certificates were compromised. One, published by the researcher Flüpke, is literally the number 4.
Why it matters: with those keys, anyone could create fake certificates for any website, in any country, that browsers would accept without a warning.
The fix: Chrome, Firefox, Apple, Microsoft and Go blocked the keys between October 17 and 20, mostly automatically. Node.js shipped a fix on October 21.
What you should do: keep your browser, phone and operating system updated. Nothing else is needed.

What a certificate authority is, and why the web needs one

A certificate authority (CA) is a trusted third party that confirms a website really is who it claims to be. It works like a passport office for websites.

The problem it solves

When you type yourbank.com, your connection passes through many machines you don't control: your Wi-Fi router, your internet provider, routers across the internet. Any of them could answer "Hi, I'm yourbank.com!"

HTTPS encryption stops strangers from reading your traffic. But encryption alone doesn't tell you who is on the other end: you could have a perfectly encrypted conversation with a scammer. Your browser needs a way to check that this really is your bank.

How it works

The website proves to a CA that it really controls its domain.
The CA issues a certificate: a digital ID card saying "this key belongs to yourbank.com," stamped with the CA's signature.
When you visit, the site shows that ID card, and your browser checks the stamp.

Screenshot 2026-10-23 at 11.56.42 AM.png

How a certificate gets trusted · 4 steps

A scammer on your Wi-Fi can't get that stamp, because the CA won't vouch for a domain they don't control. Their fake site has no valid ID, and your browser shows a big warning.

Why your browser trusts the CA

Your browser and operating system ship with a built-in list of trusted CAs. Google, Mozilla, Apple and Microsoft each decide who is on their list. CAs must pass audits and follow strict rules to stay there.

In practice, the chain has three levels. A root CA sits on the trusted list. It signs intermediate CAs, which do the day-to-day signing of website certificates.

The catch

The whole system relies on each CA keeping its signing key secret: the stamp only means something if only the CA can make it. The trusted list is global, and any trusted CA can stamp an ID for any website in the world. So one careless CA weakens everyone.

What happened

A security researcher reported the weak keys to Apple, Google, Microsoft, Mozilla and eMudhra on October 17, 2026. After Mozilla made the issue public on October 20, others published the keys too, including the chaos.social thread below, which showed one of them was the number 4.

The thread contained:

A private key in PEM format for the intermediate certificate C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C.
The claim that the private key value (called D) is 4, "no joke."
A proof anyone can run: two openssl commands that hash the public key derived from the leaked key, and the public key inside eMudhra's real certificate. If the two hashes match, the leaked key is the real one.
Supporting material: a GitHub Gist with the certificate, and a repository (jokingly named emudrahahahahaha) with all the compromised intermediates and their keys.

The verification commands

openssl pkey -in key.pem -pubout -outform DER | openssl dgst -sha256
openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Another user, jaseg, replied asking how nobody had noticed earlier. It's a fair question: CAs are audited specifically to catch problems like this.

The browser makers had already been told. A security researcher reported the compromise to Google's Chrome Root Program and to Mozilla on Saturday, October 17, and both had blocked the keys before the thread went up.

Why a key of 4 is so bad

A CA's private key must be a huge random number nobody can guess; eMudhra's could be guessed in four tries.

	What the key should be	What eMudhra's key was
Value	A random 384-bit number	47 zero bytes, then 04
Size	About 115 digits long	The number 4
Time to guess	Longer than the age of the universe	Four tries

The key is an elliptic-curve key on the P-384 curve. Its matching public key is simply 4 × G, where G is the curve's standard starting point. Anyone who checked for tiny keys would have spotted it. The other seven keys are just as weak: each is a whole number below 256, the largest being 237, so none takes more than 255 tries. The certificates table below lists all eight.

eMudhra says the keys were generated on FIPS 140-2 Level 3 hardware security modules, and that a flaw in a key wrap/unwrap step during its April 2025 key generation ceremony produced a second, weak set of keys alongside the strong ones. The weak keys were the ones published to browser root stores, and they went unnoticed through two independent audit cycles. eMudhra has not yet confirmed the exact root cause.

How an attack would have worked

With the key, an attacker could make a fake ID for any site, and before October 17 your browser would have accepted it with the normal padlock.

Screenshot 2026-10-23 at 11.57.05 AM.png

Attack path · 4 steps, before vs after the fix

The attacker still needs to sit between you and the site, which is called a man-in-the-middle (MITM) attack. Since the browser updates of October 17–20, an up-to-date browser recognizes the leaked keys and refuses anything signed with them.

The affected certificates and how vendors responded

Eight eMudhra intermediate certificates were compromised, and every major browser blocked the six website-issuing ones within three days of the report.

The eight certificates

Certificate	Type	Used for	Private key (d)
EM DV TLS CA - G3B	Domain validated	Websites	156
EM DV TLS CA - G3C	Domain validated	Websites	230
EM OV TLS CA - G3B	Organization validated	Websites	155
EM OV TLS CA - G3C	Organization validated	Websites	4
EM EV TLS CA - G3B	Extended validation	Websites	115
EM EV TLS CA - G3C	Extended validation	Websites	56
EM OV CS CA - G3B	Code signing	Signing software	66
EM OV CS CA - G3C	Code signing	Signing software	237

G3B certificates were issued under eMudhra BV (Netherlands) and G3C under eMudhra Inc (United States), so this isn't only an Indian problem.
The website intermediates chain to emSign Root TLS CA - G3; the code-signing ones to emSign Root CS CA - G3.
Sectigo, a large international CA, had cross-signed the same keys. That's why vendors blocked the keys themselves, not just eMudhra's certificates.
eMudhra has revoked all eight, with the reason recorded as CA compromise.

Timeline

When (UTC)	Who	What happened
Oct 21	Node.js	Ships Node.js 22.23.4, 24.22.1 and 26.12.1, which update the bundled CA certificates to cover the eMudhra compromise.
Oct 20	Electron	Ships Electron 44.9.1, 43.8.1 and 42.11.16, which add the eight keys to its certificate blocklist. Node.js's fix was ported from this patch.
Oct 20	Go	Releases Go 1.27.3 and 1.26.10, which reject any chain using the eight keys, with no opt-out.
Oct 20	Mozilla	Ships Firefox 158.0.1, ESR 115.43.1, ESR 153.5.1 and NSS 3.131.1, and removes emSign ECC Root CA - G3 from its trust store.
Oct 20	Microsoft	Blocks the certificates.
Oct 19	Apple	Apple devices block the certificates.
Oct 18	eMudhra	Revokes all eight intermediates.
Oct 17, 22:59	Mozilla	Finishes pushing a OneCRL block to all standard Firefox installs, under 3 hours after the report.
Oct 17, 20:06	Mozilla	Receives the report.
Oct 17, 19:45	Google	Chrome confirms the findings and pushes a CRLSet block of the six website intermediates by key.
Oct 17, 18:05	Google	A security researcher reports the compromise to the Chrome Root Program.
Mid-2025	Root programs	eMudhra's G3 hierarchy is included in browser trust lists.
May 2025	Sectigo	Cross-signs all eight keys under its AAA Certificate Services root.
Apr 30, 2025	eMudhra	Creates the eight intermediates in a key generation ceremony. A flaw in a key wrap/unwrap step produces a second, weak set of keys, and those are the ones that get published.

Notes on the responses

Chrome blocked by public-key hash, which also caught the Sectigo cross-certificates, with no browser update or restart. The two code-signing CAs didn't need blocking, because Chrome won't use them to trust a website. Google is also working with Certificate Transparency logs to reject certificates from these intermediates, and says it is evaluating eMudhra's remaining CA certificate.
Go services that talk to sites still using eMudhra certificates will see those connections fail after rebuilding, until those sites get new certificates.
Node.js's October 21 security release (22.23.4, 24.22.1 and 26.12.1) updates its bundled CA certificates to cover the compromise. End-of-life versions, such as Node.js 20 and older, stay affected.
Other software is catching up: Python users depend on the certifi CA bundle, Homebrew's ca-certificates excludes the relevant emSign roots, a Composer bundle change is pending, and NetBSD published blocking instructions.

Who is affected and what to do

Before the fix, potentially everyone on the internet was exposed; now it's mainly people and systems running outdated software.

Global impact

The list of trusted CAs is the same worldwide, and any trusted CA can sign for any domain. A forged certificate for a Brazilian bank, signed with one of these keys, would have worked on an unpatched browser in Brazil, Germany or anywhere else.

Who is still at risk

Old phones or computers that no longer get updates. Devices whose trust store stopped updating before mid-2025 never got eMudhra's G3 roots, but they may still trust Sectigo's older AAA Certificate Services root, which cross-signed the same keys in May 2025.
Firefox installs with custom settings that block automatic revocation updates.
Servers and apps built with old Go or Node.js versions, or outdated CA bundles (Python's certifi, Docker images, embedded devices).

Website owners with eMudhra certificates are affected differently: those certificates may stop being trusted, and they need new ones from an uncompromised CA.

What limits the risk

A fake certificate alone isn't enough to attack someone. The attacker must also intercept the victim's connection, for example through a malicious Wi-Fi network, a compromised router or provider, or DNS hijacking. There's no public evidence so far that anyone did.

What to do

Regular users

Keep your browser, phone and operating system updated. That's all.

Developers and system administrators

Rebuild Go services with Go 1.27.3 or 1.26.10 or later.
Upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1, and rebuild container images and tools that bundle their own Node.js.
Update CA bundles: certifi, OS ca-certificates packages, container base images.
Check whether any of your sites or APIs use eMudhra or emSign certificates, and replace them.
Find out which trust stores your software relies on and how each one receives revocations.

The NodeSource Blog