Dart and Flutter Fixed a TLS Certificate Flaw: What GHSA-frr6-h895-5pxp Means for Your App

On October 23, 2026, the Dart team published a High-severity security advisory, GHSA-frr6-h895-5pxp, fixing a TLS man-in-the-middle issue tied to compromised certificate authority keys. If your Flutter app makes network calls on Android, Windows, or Linux, you need to know about this one, and you need to ship a rebuild, not just update your local SDK.

What actually happened

In October 2026, eight intermediate CA certificates issued by eMudhra turned out to have been generated with weak cryptographic entropy. That's bad in a specific way: it means an attacker could derive the private keys from the public certificate data and forge a valid HTTPS certificate for any domain they wanted, not just one eMudhra had issued.

Google caught this first. Chrome's Root Program confirmed the report and pushed a CRLSet update on October 17, 2026, blocking the affected intermediates by their key hash, no browser update or restart required. Android devices got the equivalent protection through Google Play Services around 22:00 UTC the following Monday (a device restart applies it immediately). According to Google's own post, no certificates chaining to the compromised CAs were ever logged in Certificate Transparency before the block went out, so there's no confirmed case of this actually being exploited in the wild.

Why Dart and Flutter needed a separate fix

Chrome's and Android's fixes protect the browser and the OS's own HTTPS traffic. They don't protect your Flutter app, because dart:io ships with its own BoringSSL-based TLS stack and its own certificate trust handling, separate from the platform's. Per the advisory, on Android, Windows, and unpatched or containerized Linux, apps using dart:io for outbound TLS kept trusting the compromised intermediates until the SDK itself was patched.

The fix updates BoringSSL to distrust the specific compromised intermediates, and on Android 14+, loads system roots from the updatable Conscrypt APEX module instead of a bundled list. Web, iOS, and macOS builds aren't affected, those rely on the platform's own certificate handling rather than Dart's bundled store.

Are you affected

• Your app uses dart:io for networking, directly or through http, dio, raw sockets, or WebSockets. That's most non-web Flutter apps.
• It runs on Android, Windows, or Linux.
• iOS, macOS, and Flutter web builds are not affected, per the advisory.

What to do

1. Check your current versions: dart --version and flutter --version.
2. Upgrade: Dart SDK to 3.13.7+ (stable) or 3.14.0-315.3.beta+ (beta); Flutter SDK to 3.47.8+ (stable) or 3.50.0-0.2.pre+ (beta). flutter upgrade pulls the matching Dart SDK with it.
3. Rebuild your app. The fix lives in BoringSSL, compiled into your app's binary. Updating the SDK on your machine does nothing for users running the app you already shipped.
4. Redeploy. Prioritize Android, Windows, and Linux builds specifically, since those are the affected platforms.
5. Separately, check your backend's TLS certificate chain. Chrome removed the root that signed the compromised intermediates, emSign ECC Root CA - G3, from the Chrome Root Store, effective October 27, 2026. If your API's certificate chains through that root, it needs reissuing from a different root regardless of what you do on the Flutter side, or Chrome-based clients hitting it directly will start failing.

Should you panic

No. Certificate Transparency logs show no forged certificates from this were ever issued before Chrome blocked the compromised keys, so there's no evidence of real-world exploitation. That said, "High severity, no known exploitation yet" is exactly the window where patching before it matters is still free. Update the SDK, rebuild, ship it.

Sources: GHSA-frr6-h895-5pxp, Google's advisory post