Guessable CA Keys: Why Flutter 3.47.8 Is a Mandatory Update

This is a live, exploitable flaw: with a guessable CA key, an attacker can impersonate any server to a Dart-based client that trusts the root. Upgrading to 3.47.8 and republishing is the only way to close the TLS hole, and with 2 of the 8 keys being Microsoft code-signing certs, the blast radius extends beyond HTTPS.

Indian CA eMudhra used a flawed key-generation script in its HSM in April 2025, producing a second set of weak backup keys that later got used for real CSRs. The 8 intermediate certificates revoked in October 2026 have private keys that are 3 to 8 bits long; the actual values are 4, 56, 66, 115, 155, 156, 230, and 237. An attacker enumerating 1 to 255 on a laptop can recover one of these keys in under a second and sign a certificate for any domain.

Browsers and operating systems moved to block the compromised chains: Chrome's CRLSet, Mozilla's OneCRL, Apple and Microsoft updates. Flutter's default network stack, dart:io, keeps its own BoringSSL and a bundled Mozilla root store, and it never reads those revocation lists. So a Flutter app can still finish a TLS handshake with a revoked, forged certificate. Flutter 3.47.8 adds the intermediate CAs to BoringSSL's blacklist and, on Android 14+, starts pulling system root certificates from the updatable Conscrypt APEX module, so future revocations reach apps without a full release.

Upgrading the SDK alone doesn't shrink the exposure: old app versions in the field still carry the old trust store. Teams need to decide between a forced update, a risk warning, or a normal release, and for account/payment scenarios, coordinate with the server side. The risk assessment turns on whether the app reaches multiple public services, or only a single backend with extra authentication like pinned public keys.