On 17 October 2026 a researcher reported to the Chrome Root Program that several intermediate certificate authorities run by eMudhra had generated their keys with too little randomness. The private keys can be worked out from the public certificates. Anyone who does that can make a certificate for any domain, including your API, that unpatched software accepts as valid.
Browsers were fixed quickly. Chrome blocked the certificates the same evening, and Android got the block through Google Play Services two days later. Apple blocked them on its platforms too. But a lot of software does not ask the browser or the operating system whether a certificate is trusted. It carries its own list, and that list only changes when someone updates or rebuilds it.
Below is what we checked for our clients’ apps and our own servers, so you can do the same.
What Can Actually Happen
Someone who controls the network between your app and your API can present a forged certificate for your API’s domain. An app that still trusts the compromised certificates accepts it without any warning. The attacker passes the traffic on to the real server, so the app keeps working normally, while logins, tokens and customer data pass through their hands.
Controlling the network sounds hard, but a fake hotspot at a trade fair, a station or a warehouse is enough. That is why this matters most for mobile apps, and less for servers in a data centre.
Who Is Affected
| Software | Affected? | What to do |
|---|---|---|
| Chrome, Firefox, Safari, Edge | No, blocked within days | Nothing |
| Native iOS and macOS apps | No, blocked by Apple | Nothing |
| Native Android apps | No, Play Services update on 19 October | Nothing |
| Flutter apps on iOS, macOS and web | No | Nothing |
| Flutter apps on Android and Windows | Yes, until rebuilt | Rebuild on Flutter 3.47.8 / Dart 3.13.7 or later and release |
| Flutter on Linux | Depends on the system certificate list | Update the ca-certificates package |
| Node.js | Older versions | 22.23.4, 24.22.1, 26.12.1 or later |
Python with certifi | Older versions | certifi 2026.10.19 or later |
| Docker images and Linux servers | If built or updated before about 20 October | Rebuild with security updates |
For containers, the certificate list inside the image is the one that counts, and it is fixed at the moment the image was built. Alpine, Ubuntu and Debian 12 and 13 all shipped updated ca-certificates packages between 20 and 21 October, so a rebuild that installs security updates picks them up.
One detail makes this trickier than removing a single root certificate. The compromised intermediates were also cross-signed by an older Sectigo root, AAA Certificate Services, that many certificate bundles still contain. Removing the eMudhra root alone is not enough: either that older root goes too, as in Debian’s update, or the intermediates are blocked directly, as in the Flutter fix.
How to Check Your App
Ask whoever builds your app two questions:
- Which Flutter version was the last Android and Windows release built on?
- If it is older than 3.47.8, when is the new build going out?
If the answer is a version number and a date, you are in good shape. Once the new build is live, raising the minimum app version makes sure nobody keeps using the old one.
There is also a good side effect. On Android 14 and up, apps built on the fixed Flutter version load their trusted root certificates from a part of Android that Google updates through Play system updates. The next time something like this happens, those apps pick up root certificate changes without a new build.