Every time you see the padlock next to a website address, a company called a certificate authority is vouching that the site is who it says it is. This week we learned that one of those companies, India's eMudhra, created eight of its secret signing keys so weakly that anyone could work them out from public information. Researcher Scott Helme said he recovered all eight in under a second. One key was the number 4. The others were small numbers below 256. A proper key is a random number so large there are more possibilities than atoms in the universe.
With those keys, someone could have made a fake bank or email site that your browser would have trusted. Browsers fixed it within hours of the October 17, 2026 report, and no attack has been confirmed. But the story is a useful lesson in how internet trust works, why updates matter, and where the remaining risk sits. It broke the same week as PHP2Shell and the Node.js security updates. For the technical version aimed at engineers, see AgentBeam's eMudhra deep dive.
The short version
| Question | Answer |
|---|---|
| What broke? | Eight of eMudhra's secret signing keys were guessable |
| What could go wrong? | Fake websites or fake software that look genuine |
| Was anyone attacked? | Not confirmed |
| Am I safe in my browser? | Yes, after updating. All major browsers block the bad certificates |
| Who still needs to act? | Developers and companies running servers, apps and containers |
| Indian DSC and eSign? | eMudhra says they are separate and unaffected |
| What did it cost eMudhra? | Its shares fell 20% in Mumbai on October 21, according to The Hacker News |
First, how the website padlock works
Imagine a notary who stamps documents to prove they are real. Your browser carries a short list of trusted "notaries" called certificate authorities (CAs). When you visit a site, it shows a certificate stamped by one of them, and your browser checks the stamp.
Big CAs do not stamp every certificate with their main key. They create "intermediate" keys for daily work, a bit like a notary's assistants. eMudhra made eight such assistant keys in April 2025. Because of a mistake in how they were created, the secret part of each key was tiny and easy to guess. Anyone who guessed it could stamp certificates for any website they liked.
eMudhra's weak certificate keys could be worked out like a simple puzzle
What happened, step by step
| When | What happened |
|---|---|
| April 2025 | eMudhra creates the eight intermediate keys in a formal "key ceremony" |
| October 17, 2026 | A researcher, credited only as "Wayne," reports the weak keys to Google and Mozilla. He proves it by signing the message "We have a problem here" with each key |
| Within hours | Chrome and Firefox block the eight certificates |
| October 18 | eMudhra cancels (revokes) the certificates |
| October 19 | Apple blocks them; Android gets a block through Google Play Services |
| October 20 | Microsoft blocks them; fixes ship for Go and Firefox; Google and Mozilla confirm publicly |
| October 21 | eMudhra makes a statement to the stock exchange; Node.js ships a fix |
The speed is the good news. Browser makers can push a block list to billions of devices in hours. Mozilla says its team worked out the keys within two hours of the report.
How did this happen?
Accounts differ slightly:
- eMudhra says a fault in one step of the key ceremony produced a second, weak set of keys next to the strong ones it meant to create, and the weak ones were the ones sent to browser makers. It says its hardware met official security standards and its investigation continues.
- Google says the keys simply had too little randomness, so they could be calculated from public certificates. Nothing had to be stolen.
eMudhra also says its systems were not hacked, no data was breached, only one of the eight keys was used in production, and none was ever used to stamp a customer's website certificate. Public logs back up the last part: no website certificate made with these keys appeared in the logs browsers rely on before they were blocked.
Am I affected? Find yourself here
| You are... | Risk | What to do |
|---|---|---|
| Using Chrome, Firefox, Safari or Edge | Very low once updated | Keep your browser and phone updated |
| Using an old phone, TV or gadget that never updates | Some, in theory | Replace or stop trusting devices that no longer get updates |
| A website owner with an eMudhra certificate | Your certificate may stop working | Get a replacement; eMudhra says it is issuing them |
| A developer | Your tools may still trust the bad keys | Update runtimes and rebuild containers (below) |
| A company in India using eMudhra DSC or eSign | eMudhra says those systems are separate | Ask your account manager to confirm in writing |
What to do
Everyone
- Turn on automatic updates for your browser, phone and computer, and install any pending ones.
- Optional check: open
emudhra.we-have-a-problem.comin your browser. If you see an error or "can't connect," your device is protected. That is the good result.
Developers and people who run servers
Browsers check for cancelled certificates. Many developer tools do not. They trust a list of authorities bundled when the tool was built, so they keep trusting the bad keys until they are updated. The main fixes:
- Node.js: update to 22.23.4, 24.22.1 or 26.12.1. These add a built-in block for the eight keys.
- Go: rebuild your programs with Go 1.27.3 or 1.26.10.
- Python: update the
certifipackage to 2026.10.19. - Your operating system: install the latest
ca-certificatesupdate. - Docker: rebuild your images so they pick up the new certificate lists.
A quick test from a server or container (an error is what you want):
curl https://dv-g3b-emudhra.we-have-a-problem.com/
AgentBeam's deep dive has the full list of fixed versions and test commands for Python and Node.js.
Rebuilding apps and containers so they stop trusting the eMudhra certificates
One mistake to avoid
After these updates, some apps may show certificate errors. If an AI coding assistant suggests "fixing" that by turning off certificate checks (settings like verify=False or NODE_TLS_REJECT_UNAUTHORIZED=0), say no. Cloudflare put it plainly: "It's important to not resolve these errors by disabling verification." Turning checks off removes exactly the protection the updates restore.
Why this matters for people building with AI
Most AI apps and agents talk to servers from code, not from a browser: Python and Node.js SDKs, background services, containers and agent sandboxes. Those are the tools that kept trusting the bad keys longest. There is no report of anyone abusing this against AI tools. Still, if you build with AI, this is the moment to rebuild your containers and update your runtimes.
It is also a reminder about AI-written code. Coding assistants are good at making errors disappear, sometimes by switching off a safety check. Our coverage of security basics for AI agents and how secure vibe-coded apps are shows how often that kind of shortcut slips through. If agents work on your machines, AgentBeam records the commands and file changes they make, so a disabled check shows up when you review their work.
The India angle
eMudhra is one of 14 certifying authorities licensed by India's Controller of Certifying Authorities (CCA), and says it has issued over 60 million digital certificates. For most people in India, the name means the digital signature certificates (DSCs) used for tax filings, company filings and eSign. Medianama notes that UIDAI's website lists eMudhra as its certificate issuer.
eMudhra says its Indian DSC and eSign services run on separate infrastructure and kept working normally. Medianama reported that CERT-In and the CCA had not issued public advisories at the time, and that the Internet Freedom Foundation planned to write to MeitY, the CCA and CERT-In. Policy analyst Pranesh Prakash called the lapse "inexplicable" but said it may be a single error rather than a deeper problem. Developer Abhay Rana warned that heavy-handed government intervention could further hurt trust in India's certificate authorities.
For Indian businesses and government teams, the practical step is the same as anywhere: browsers are fixed, but older servers, Java apps and appliances need their certificate lists updated. It follows CERT-In's advisory on AI agents accessing Indian organisations' live systems as another sign that patching speed matters.
What is confirmed, and what is only claimed
| Statement | Status |
|---|---|
| Eight keys were guessable | Confirmed by Mozilla, Google and independent researchers |
| One key was the number 4 | Reported by Scott Helme; others found similar small numbers |
| Nobody was attacked | Not confirmed either way; nothing in public logs before the block |
| No customer certificates were issued from these keys | eMudhra's claim, supported by public logs |
| Indian DSC and eSign are unaffected | eMudhra's claim |
| HTTPS is broken | False. This was one company's key mistake, not a flaw in HTTPS |
Words you might see in other coverage
| Term | Plain meaning |
|---|---|
| Certificate authority (CA) | A trusted company that vouches for websites, like a notary |
| Intermediate certificate | An "assistant" key a CA uses for daily stamping |
| Private key | The secret part of a key. Whoever has it can stamp certificates |
| Revocation | Cancelling a certificate before it expires |
| Trust store | The built-in list of CAs your device or app trusts |
| Certificate Transparency (CT) | Public logs of every website certificate, which browsers check |
| TLS / HTTPS | The technology behind the padlock |
The bigger lesson
Internet security depends on a few secrets being truly secret and truly random. eMudhra's failure was not a clever hack, which is what makes it unsettling. It is also a good reason to check big security claims instead of taking them on trust. The browser world responded in hours. The slow part is everything else: servers, containers, gadgets and apps that only get safer when someone updates them.
Related reading on explainx.ai
- PHP2Shell explained: what happened and what to do
- Node.js October 2026 security updates explained
- CERT-In advisory: AI agents accessed Indian organisations' live systems
- AI labs probing cryptography: claimed vs verified
- RSA-260 factored: verify it yourself
- Capsem: a VM sandbox for coding agents
Sources: Mozilla incident page · Cloudflare · The Hacker News · The Register · Medianama
Accurate as of October 21, 2026. Fixes are still rolling out; check Mozilla's tracking page for the latest list.