The short answer
If your app is built with Flutter, or uses Google’s Cloud Firestore on iOS, you very likely need to rebuild it on an updated SDK and push an update through the stores. A phone update will not fix it for you.
On 17 October 2026 a researcher showed that the private keys of eight intermediate certificate authorities run by eMudhra, an Indian certificate company, had been generated with too little randomness, so anyone could work them out. Those keys could be used to create HTTPS certificates that look valid for any website. Browsers and phone makers blocked them within days. Apps that carry their own copy of the trusted-certificate list did not get that protection.
This page covers what happened, which apps are affected, the ten-minute check, and the part most Indian business owners have been asking about: their digital signature for GST and MCA filing is fine.
This is general information to help you brief your developer, not security or legal advice. Check the official pages linked below before you act, because some details were still changing as we wrote this.
What happened, in dates
| Date (2026) | What happened | Source |
|---|---|---|
| 17 October | A researcher reported weak keys in eight eMudhra intermediate CAs. Chrome blocked the six that issue website certificates the same evening. | |
| 17 October | Firefox blocked the affected certificates through its remote blocklist. | Mozilla |
| 18 October | eMudhra revoked all eight intermediates. | eMudhra |
| 19 October | Apple began blocking 12 related certificates. Google pushed an equivalent block to Android through Google Play Services. | Apple, Google |
| 23 October | Apple also blocked the root, emSign ECC Root CA - G3. | Apple |
| 27 October | Chrome’s removal of emSign ECC Root CA - G3 from its root store was due to reach all devices. |
Two things in that table matter for a business owner. First, the platforms moved fast, so most people browsing on an updated phone or laptop were protected within a day or two. Second, the root removal means some legitimate website certificates stop working in Chrome. Google’s guidance is that operators with certificates chaining to that root must replace them with one from another provider.
On the question everyone asks first: Google says no website certificate from the six affected intermediates had appeared in public Certificate Transparency logs before Chrome blocked them. That is reassuring, not proof that nothing happened. In a statement reported by Business Today on 21 October, MeitY said the impact on Indian websites and applications had been “very limited and for a very short interval”.
Is your DSC, eSign or GST filing affected?
No. This is the most common worry we have heard from Indian businesses this week, because eMudhra is best known here for the digital signature certificates used on GST, MCA and income tax portals.
MeitY says the Digital Signature Certificate and eSign services regulated by the Controller of Certifying Authorities were not affected, according to the same Business Today report. eMudhra’s own incident page says the same, and says its DSC and eSign users need to take no action. The problem sat in eMudhra’s global website (TLS) certificate business, which is a separate system.
So you do not need to buy a new DSC because of this. What you may need to look at is your app.
Which apps need an update
The phone protects apps that ask Android or iOS “is this certificate trustworthy?” Google and Apple updated those answers remotely. The gap is apps that ship their own list of trusted roots inside the app. Google’s Firebase guide (updated 27 October) removed the affected roots from several SDKs and lists who is affected:
| If your app is… | Firebase’s fix |
|---|---|
| Flutter, targeting Android, Windows or Linux | Rebuild with Flutter 3.47.8 or later (Dart 3.13.7 or later) and republish |
Flutter using cloud_firestore on iOS, macOS or Windows |
Update to cloud_firestore 7.1.0 (BoM 5.1.0+), or the listed 6.10.x patch, then rebuild and republish |
| Native iOS or macOS using Cloud Firestore | Update FirebaseFirestore to 13.1.1 or later, or 12.19.3 (the CocoaPods fix) |
| Unity or C++ using Firestore on Apple or desktop | Update to 14.1.0 or later, or the listed 13.x patch |
| Native Android using the Firebase App Distribution Gradle plugin | Update the plugin to 5.3.1 or later; no app release needed |
Firebase lists Flutter apps as affected “regardless of target platform or product”, which is why we treat every Flutter app as needing a rebuild on the fixed SDK rather than trying to argue a build out of scope. Firebase also says its Firestore and App Distribution backends were not affected. The issue is in the app, not in Google’s servers.
Why an OS update is not enough
The fixed certificate list is compiled into the app. Firebase’s guide says plainly that operating system updates or server-side changes alone do not fix builds already installed on people’s phones. Every user stays on the old trust list until they install your new version. That makes this a release problem as much as a code problem: the fix only counts once it is live and users have updated.
The ten-minute check to ask your developer for
You do not need to read code to get a clear answer. Ask whoever maintains your app for five things:
- The output of
flutter --versionon the machine that builds your releases. Below Flutter 3.47.8, the Android build needs redoing. - The
cloud_firestoreline inpubspec.lock, if the app uses Firestore. - The
FirebaseFirestoreversion inPackage.resolvedorPodfile.lockfor native iOS apps, and whether the Podfile pins an old version. - The App Distribution plugin version in the root Gradle file, if you send test builds that way.
- The date and version of the last release on Google Play and the App Store, so you know which build your users actually have.
If the answers come back within the hour, you are in decent shape. If nobody can find the source code, the signing key or the store login, that is a bigger risk than this incident, and it is the pattern we described in the handover tax: the people who built it and the people who now own the problem are not the same.
Does your website or API need a new certificate?
Your app talks to a server, and that server has its own certificate. It needs a look only if the certificate was issued by eMudhra or emSign.
Open your website in Chrome, click the icon left of the address, and view the certificate details. If the issuer mentions emSign or eMudhra, talk to your hosting provider now. Google says certificates chaining to emSign ECC Root CA - G3 stop working in Chrome after the root removal. eMudhra says it is moving remaining customers to alternate providers at no cost, and has said it will wind down its publicly trusted TLS business. Even a certificate on an unaffected eMudhra chain will need a new home soon.
According to eMudhra, the roughly 30,800 certificates under the affected hierarchy belonged to one US client ecosystem, so most Indian small-business websites are unlikely to be on it. The check takes a minute, so do it anyway.
What we would do this week
If we were looking after your app, this is the order we would work in:
- Rebuild on the fixed SDK first. Upgrade Flutter and the Firebase packages, run the app’s tests, and check payments, login and push notifications on a real low-end Android phone, because SDK jumps sometimes break plugins.
- Ship the update to both stores. Write release notes that say “security update” without causing alarm.
- Decide whether to require the update. For apps handling logins, payments or personal data, a required update is reasonable once the new build is live.
- Check the server certificate. It is a one-minute check, and it closes the other half of the question.
- Write down who holds what. Source code, signing keys, store accounts and hosting, each in your company’s name. The next incident will be easier.
None of this means rewriting the app. For most Flutter apps it is a short SDK upgrade, a test pass and a store release, as long as the project was kept reasonably current. Apps left untouched for a year or more can take longer, because the upgrade pulls other dependency updates with it.
Where Akvega fits
We build and maintain Flutter apps, and we run the hosting and backends behind them. If you want a second pair of eyes, send us your Flutter version, your lock files and your store links through the contact page. We will tell you whether a rebuild is needed and what it involves before anyone starts work. You can also read how we approach mobile app builds.