Flutter's Emergency 3.47.8 Release Blocks a Certificate Authority Whose Private Key Was the Number 4

Flutter rushed out Flutter 3.47.8 and Dart 3.13.7 over the weekend, after an Indian operator's sloppy move got exposed. eMudhra's CA certificate key leaked, and the reason for the leak is that its certificate key was a single digit, for example a 4. Yes, you read that right: the certificate key was literally 4.

An ordinary P-384 elliptic curve private key is a random integer close to 384 bits; in theory there should be 2^{384} possibilities. Yet eMudhra's 8 private keys turned out to be the following numbers:

A company that does digital trust for a living made its intermediate CA private keys single-byte integers, then hung them on the global trust chain for a year and a half. What kind of thrill ride is that? The reason: an employee misread the values when publishing them.

Which means anyone can now forge this company's "legitimate" CA. An attacker can use a network path to forge valid TLS/HTTPS certificates for any domain. To block the compromised eMudhra intermediate CA certificates, you now need to upgrade Flutter to stay safe.

Although browsers and operating systems have published emergency intermediate certificate blacklists, dart:io on Android, Windows, and Linux uses the built-in BoringSSL engine to verify TLS certificate chains. It does not read the operating system's intermediate certificate blacklist. So this release is mainly about updating BoringSSL to directly block the compromised eMudhra intermediate certificates during TLS verification.

Additionally, on Android 14+, dart:io now loads system root certificates from the updatable Conscrypt APEX module, ensuring that future over-the-air root store revocations delivered through Google Play system updates take effect automatically.

Of course, if your released app simply ignores certificate verification entirely, then I'll say no more.