Flutter eMudhra checker: is your app affected?

In October 2026, eight intermediate CA certificates issued by eMudhra were found to be compromised: their keys were generated with weak entropy, so an attacker can derive the private keys and forge valid HTTPS certificates for any domain. Browsers and operating systems now distrust them, but on Android and Windows, Dart's dart:io uses its own built-in copy of BoringSSL and doesn't read the operating system's blocklist. A Flutter app built with an older Dart SDK keeps trusting those certificates, so someone on the network path (public Wi-Fi, a compromised router) could intercept its HTTPS traffic. The official advisory is GHSA-frr6-h895-5pxp (severity High, published 23 October 2026).

Likely, if it was built with Dart below 3.13.7 on the stable channel (below 3.14.0-315.3.beta on beta), which means Flutter below 3.47.8 (or 3.50.0-0.2.pre on beta), and it makes HTTPS connections through dart:io (for example the http or dio packages on their default client). Android and Windows builds are affected, and Linux builds that run in a static container or on a host without updated CA certificates. iOS, macOS and Web builds are not.

Upload your release .apk or .xapk above. We open it as a zip archive, find the Flutter engine (libflutter.so) and read the Dart version it was built with, then compare it with the fixed versions in the advisory. You get the result on this page; add an email if you also want it with the fix steps. If you build the app yourself, `flutter --version` on your build machine or in CI shows the same thing.

No. On iOS and macOS, Dart uses Apple's Security.framework to verify certificates, and on the Web the browser does it, and those already distrust the compromised eMudhra certificates. Android, Windows and some Linux builds are the ones that need a rebuild.

Because a static check of the SDK version can't confirm it. Apps that make their network calls through native Android APIs (for example cronet_http, or your own platform channel) instead of dart:io aren't affected. And some teams use an SDK with the fix backported, which still reports the old version number. If your result is likely affected, a short review of how the app talks to the network settles it.

Upgrade Flutter to 3.47.8 or later (stable; 3.50.0-0.2.pre or later on beta) with `flutter upgrade`, check that `flutter --version` reports Dart 3.13.7 or later, then rebuild and release your Android app and any Windows or Linux builds. The fix updates BoringSSL to distrust the eMudhra intermediates; on Android 14 and later, dart:io also loads the system's updatable root store. Users stay exposed until they install the rebuilt version.

We read it, we never run it. The checker doesn't install or execute the app, makes no network call and doesn't contact any server the app uses. It reads only the few files inside the archive it needs (the Flutter engine library and the app's manifest), then deletes the upload and everything read from it as soon as the check finishes. We keep only the result: the app's name or package, the Dart version and the verdict.

If you build it: `flutter build apk --release` writes build/app/outputs/flutter-apk/app-release.apk. If you ship an app bundle (.aab), build a universal APK from it, or upload the .xapk. From an installed app: `adb shell pm path <package>` lists its APK files; upload the one with libflutter.so (usually the ABI split, such as split_config.arm64_v8a.apk) or all of them as one .xapk.

Usually because the file has no Flutter engine inside: a base APK from a split install keeps libflutter.so in a separate ABI split. Upload the full .xapk or a universal APK. It can also mean a custom engine build without the standard version string, or a dev-channel SDK that the advisory doesn't cover.

Yes: no account, no card and no email needed. Uploads up to 95 MB, a few checks per hour from one network.