Published October 26, 2026

Flutter 3.47.8 Security Update Distrusts Compromised eMudhra Certificates

Google published a high severity security advisory for the Dart and Flutter SDKs on October 23, 2026, after eight intermediate certificate authority certificates issued by eMudhra were publicly disclosed as compromised. The weakness allows an attacker positioned on the network path to derive the corresponding private keys and forge valid TLS certificates for arbitrary domains.

The advisory carries the identifier GHSA-frr6-h895-5pxp and is classified under CWE-295, improper certificate validation. No CVE has been assigned. Severity is rated high, and the practical exposure is concentrated in a place many Flutter teams do not think about: the certificate store baked into their compiled binaries.

What Is Actually Broken

The root cause sits outside Dart entirely. Weak key generation entropy in the issuance process made the private keys for these intermediates derivable without breaching a server. An intermediate certificate sits between a trusted root and the leaf certificates a site presents, which means a forged chain signed by one of these intermediates verifies normally on any client that still trusts it.

Browsers and operating systems responded by removing the affected intermediates from their trust bundles. Chrome shipped a blocklist update, and Android did the same through its system components. Dart and Flutter applications on Android and Windows are a different story, because `dart:io` verifies TLS chains using a BoringSSL copy compiled into the application itself. Those binaries never consult the operating system blocklist, so the revocation never reaches them.

Who Is Affected

  • Android and Windows: affected, because `dart:io` validates chains against the compiled-in BoringSSL engine
  • Linux: affected only where the system ca-certificates bundle has not been updated, such as static containers or unpatched hosts
  • Web, iOS, and macOS: not affected, since verification is delegated to the browser or to Apple Security.framework
  • Dart SDK: stable releases below 3.13.7 and beta releases below 3.14.0-315.3.beta
  • Flutter SDK: stable releases below 3.47.8 and beta releases below 3.50.0-0.2.pre

Any application that makes outbound HTTPS connections over `dart:io` and was compiled with an affected SDK remains exposed until it is rebuilt with a patched one. That includes package applications shipped through stores as well as internal tools, command line utilities built with Dart, and desktop binaries distributed outside any store.

What the Patch Changes, and What to Do

Two changes matter. The first is that BoringSSL was updated so that the compromised eMudhra intermediates are explicitly distrusted during TLS chain verification. Trust is refused at the engine level rather than relying on an external blocklist, which is the only mechanism available to a binary that carries its own verifier.

The second change is more forward-looking. On Android 14 and above, `dart:io` now loads system root certificates from the updatable Conscrypt APEX module. That module is delivered through Google Play system updates, which means future over the air root store revocations can reach Flutter applications without waiting for an SDK release and a rebuild.

The distinction between the two is worth internalising. The BoringSSL change fixes this incident. The APEX change reduces the blast radius of the next one, but only on modern Android versions and only for applications rebuilt at least once on a patched SDK. In practice the response has four steps.

  • Upgrade to Flutter 3.47.8 or Dart 3.13.7 on stable, and confirm with `flutter --version`
  • Rebuild and redeploy every Android, Windows, and Linux artifact, since replacing the SDK alone does not change already published binaries
  • Rebuild internal Dart tooling and CI utilities that make HTTPS calls
  • Refresh the ca-certificates bundle in Linux images and pinned container bases

Verification is straightforward. Intercepting TLS traffic against a forged leaf certificate signed by one of the affected intermediates proves the fix in place, and most security suites already carry that test. The patched engine should refuse the connection outright rather than warn.

For most Flutter teams this is a version bump followed by a normal release. The teams that should move fastest are those shipping long-lived desktop builds and those distributing Dart binaries through channels that update slowly, because a rebuilt artifact is the only thing that clears the exposure. The advisory is short, unambiguous, and unusually free of ambiguity about which combinations are safe, which makes triage quick.