Eight “secret” keys anyone could guess.
One was the number 4.

What happened, in five lines

1. Your browser does not check websites itself. It trusts a few dozen companies called Certificate Authorities, which sign website certificates the way a passport office signs passports.
2. eMudhra Ltd of Bengaluru is one of the most embedded of these companies in India: licensed by the Controller of Certifying Authorities, listed on the stock exchanges, a certificate supplier to government websites.
3. Eight intermediate certificates it issued in early October had private keys a schoolchild could guess. One key was literally the number 4. An AI agent recovered a key on its first attempt.[1][2]
4. Holding those keys meant anyone on a network between you and a website could forge a valid certificate for that website and read or rewrite your traffic.
5. Firefox and Chrome distrusted all eight within hours of the 17 October report; Apple followed on 19 October. A public test site went up on 20 October. No Indian authority has published anything.[3][4]

What this means for consumers

The padlock is a promise about the pipe, not the shop

The padlock in your browser means nobody between you and the website can read or change your traffic. It does not mean the website is honest. The eMudhra failure broke the first promise: for a window of days, anyone holding those keys, on a network between you and your bank, could impersonate the bank so well that an updated-looking padlock would still appear.

Were you actually harmed?

There is no evidence any consumer was harmed. Public certificate logs show no abusive certificates were minted. To attack anyone, an attacker needed three things at once: the now-public keys, a position on the victim's network (cafe wifi, office network, hotel, an internet provider), and a victim whose device still trusted the broken keys. None of this is proof of safety. It is an accurate description of what is known.

Who is protected, and who is not

The exposed tail matters in India. The devices least likely to receive a trust-store update are old Android phones, which is the phone most Indians carry. One public report describes a three-year-old Android 12 device still trusting the affected root.[1]

Do this today

1. Update your browser, phone and laptop. Current Chrome and Firefox carry the fix. That one step covers most of the risk.
2. Test your own machine. Run these two commands in any terminal. A certificate error is good news: your tooling refuses the broken keys. If a page loads anyway, your system still trusts them and needs updating.[2]

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

3. Run servers or a business? Inventory everything that verifies certificates: build pipelines, dependency installers, Docker images, monitoring. Pin patched CA bundles (certifi 2026.10.19, Go 1.27.3, rustls-webpki 0.103.16).[5]

What we are demanding for you

An open, verifiable investigation, and a remediation path if harm is found. If it turns out someone exploited these keys against Indian users, there is today no framework that obliges anyone to tell you, and no clear answer to who makes you whole. Our open letter asks RBI, MeitY and CCA India to fix that. Read the letter.

Videos: the best explainers we found

No video dedicated to the eMudhra incident exists as of 21 October. We will add one when it appears. Meanwhile these three cover the exact mechanics: what the padlock promises, how certificate authorities work, and what happens when the trust system breaks. The first explains the same month's companion incident, where attackers got valid certificates for Google through hijacked country-code domain registries.