eMudhraの中間CA侵害で、Firestore SDKやFlutterを使う一部のアプリは作り直しが必要｜修正版の一覧と版の確かめ方

2026年11月7日

Firebaseは、eMudhraの中間CA侵害を受けてSDKの更新とアプリの作り直しを求めた

インドの認証局eMudhraが運用する8つの中間CA（ルート証明書の下で、ほかの証明書を発行する認証局）で、秘密鍵を推測できる状態だったことが分かりました。Googleは2026年10月17日、報告を受けたその日にChromeでこれらをブロックし、19日ごろにはAndroidにも同じブロックを配っています。これを受けてFirebaseは、アプリに組み込まれて動くFirestore SDKなどを更新し、対応手順の案内を公開しました（11月5日更新）。

案内で対象になっているのは、Cloud FirestoreのSDK（Apple、Flutter、Unity、C++）と、Flutter・Dartで作ったAndroid、Windows、Linuxのアプリなどです。これらは接続先の証明書を、アプリの中に組み込んだ仕組みで確かめるため、OSに届いたブロックが効きません。開発者がSDKを更新してアプリを作り直し、配り直す必要があります。

この記事では、経緯と影響するSDK、修正版を整理します。あわせて、Apple版Firestore SDKの修正前と修正後に組み込まれたルート証明書を手元で比べた結果と、自分のアプリが使っている版の確かめ方を紹介します。

対応の要点

対象のSDKを上げて作り直し、新しい版を利用者に届ける

起きたこと

中間CA 8つの鍵が弱かった

うちHTTPS用の証明書を発行できる6つは、鍵を持つ人が本物に見える証明書を作れる状態だった。

影響するアプリ

OSのブロックが効かないもの

Firestore SDK（Apple、Flutter、Unity、C++）、Flutter・Dartの Android／Windows／Linux 版など。

修正版の例

Apple版Firestore 13.1.1、Flutter 3.47.8

Apple版Firestoreは12.19.3も修正版。Dartは3.13.7以降。

利用者

アプリの更新で守られる

古い版のアプリを使い続ける間は、信頼できないネットワークで通信を傍受される危険が残る。

出典: Firebaseの案内「Updates required to remediate the eMudhra certificate compromise」（2026年11月5日更新）、Google セキュリティブログ（10月20日）

弱い鍵の中間CAは、10月17日からChromeとAndroidでブロックされた

Googleのセキュリティブログによると、2026年10月17日18時5分（協定世界時）、Chromeのルート証明書を管理するチームに、eMudhraの8つの中間CAの秘密鍵が弱い乱数で作られていて、侵害されているという報告が研究者から届きました。このうちHTTPS（TLS）用の証明書を発行できるのは6つです。鍵が分かれば、その中間CAの名前で、どのサイトのものにも見えるHTTPS証明書を作れます。

Googleは、ブロックする前にこの6つの中間CAから発行されたTLS証明書は、証明書を公開で記録する仕組み（Certificate Transparency）に記録されていなかったとしています。Chromeは、この公開記録に載っていない証明書を受け付けません。このためChromeなどでは、偽の証明書は使えなかったことになります。問題が残るのは、公開記録もOSのブロックも確かめずに、自分で持つ証明書の一覧だけで相手を確かめるソフトウェアです。

アプリの中で証明書を確かめる仕組みは、OSを更新しても変わらない

HTTPSで接続するとき、アプリは相手の証明書をたどり、信頼する「ルート証明書」の一覧に行き着くかを確かめます。多くのアプリはOSの仕組みでこれを確かめるので、OS側に届いたブロックがそのまま効きます。一方、Firebaseの案内によると、影響する製品はアプリの中に組み込んだ仕組みで接続先を確かめます。Firestore SDKはルート証明書の一覧をアプリの実行ファイルに組み込んでいて、Flutter・Dartは独自のTLSの仕組みを持つため、OSのブロックの一覧を参照しません。

Firebaseは、FirestoreとApp Distributionのサーバー側は影響を受けていないとしています。危険があるのは、アプリと接続先の間の通信に割り込める立場の攻撃者が、偽の証明書でFirestoreのサーバーなどになりすます場面です。公衆Wi-Fiのような信頼できないネットワークで、古い版のアプリを使っている利用者が対象になります。

修正版の版番号は、SDKとプラットフォームごとに違う

Firebaseの案内にある、影響するSDKと修正版をまとめます。自分のアプリが使っている行を確かめ、修正版以降へ上げます。

Windows向けのFlutterアプリでFirestoreを使っている場合は、Dart・Flutter本体と cloud_firestore の両方を上げます。Dart・Flutter本体の修正は、Firebaseを使っていないFlutterアプリにも当てはまります。Android版のFirestore SDK（Kotlin・Java）は、この案内の対象一覧には載っていません。

Apple版Firestore 13.1.1は、内蔵のルート証明書を130件から99件に入れ替えた

Apple版Firestoreの13.1.1のリリースでは、「侵害されたeMudhraの中間CAに関連するルート証明書を、組み込みの一覧から外した」と説明されています。GitHubで公開されているソースから、13.1.0と13.1.1に組み込まれた証明書の一覧を取り出し、OpenSSLで1件ずつ名前を読んで比べました。

Apple版Firestoreに組み込まれたルート証明書

13.1.0

130件

eMudhraのルートは4件（emSign Root CA - G1、ECC Root CA - G3、Root CA - C1、ECC Root CA - C3）。

13.1.1

99件

eMudhraのルートは emSign Root CA - G1 の1件だけ。ECC Root CA - G3 など3件が外れた。

入れ替え

64件外し、33件追加

共通は66件。一覧の元になる形式ごと作り直され、古いルートの整理と新しいルートの追加も含む。

2026年10月27日、firebase-ios-sdk のタグ13.1.0と13.1.1の grpc_root_certificates_generated.cc を展開し、OpenSSL 3.6.3で主体名とSHA-256を比較。修正前後の12.19.2と12.19.3を比べても、件数と増減は同じだった。

13.1.0の一覧は、ファイルの冒頭にMozillaのライセンス表記がある、gRPCに同梱されてきた形式でした。13.1.1の一覧は「root_store.textprotoが参照する証明書」という説明で始まる別の形式に変わり、件数も130件から99件に減っています。eMudhraのルートで残ったのは、emSign Root CA - G1 だけでした。

件数が大きく減っているので、Firestoreの接続先も確かめました。10月27日に firestore.googleapis.com から取得した証明書は、Google Trust Servicesの「GTS Root R4」につながっていて、新旧どちらの一覧でも検証が通りました。

$ openssl verify -CAfile bundle-13.1.0.pem -untrusted intermediates.pem leaf.pem
leaf.pem: OK
$ openssl verify -CAfile bundle-13.1.1.pem -untrusted intermediates.pem leaf.pem
leaf.pem: OK

Dart 3.13.7では、Android 14以降の端末でOSが更新する証明書の一覧を読む

Flutter・Dartの修正は、Firestoreとは仕組みが違います。Dart 3.13.7の変更履歴とソースの差分を見ると、修正は2つありました。

1. Android 14以降で読む証明書の場所を変えた。これまでは /system/etc/security/cacerts を読んでいました。3.13.7からは、Google Playのシステムアップデートで更新される /apex/com.android.conscrypt/cacerts があればそちらを読みます。ルートの追加や不信任がOS側で配られると、Dartのアプリにも反映されるようになります。
2. 内蔵のTLSライブラリ（BoringSSL）を更新した。変更履歴によると、侵害された中間証明書のブロックが含まれています。

Firebaseの案内は、Flutter・Dartで作ったAndroid、Windows、Linuxのアプリを、Dart 3.13.7以降（Flutter 3.47.8以降）で作り直して配り直すよう求めています。Flutter 3.47.8は10月23日に公開されました。iOSとmacOSについては、Firebaseの案内はFirestoreを使っている場合の cloud_firestore を対象に挙げています。

使っている版は、ロックファイルで確かめられる

アプリにどの版が入っているかは、依存関係を固定するロックファイルに書かれています。Xcode、CocoaPods、Flutterが書き出す形式に合わせたサンプルのファイルで、次のコマンドの出力を確かめました。出力は修正版を入れた場合のものです。

# Swift Package Manager（Xcodeプロジェクトの Package.resolved）
$ grep -A8 '"firebase-ios-sdk"' Package.resolved | grep '"version"'
        "version" : "13.1.1"

# CocoaPods
$ grep -o 'FirebaseFirestore ([^)]*)' Podfile.lock
FirebaseFirestore (12.19.3)

# Flutter（pubspec.lock）
$ grep -A8 '^  cloud_firestore:' pubspec.lock | grep 'version:'
    version: "7.1.0"

# Flutter・Dart 本体（筆者のMacでの実際の出力）
$ flutter --version
Flutter 3.38.5 • channel stable • https://github.com/flutter/flutter.git
Tools • Dart 3.10.4 • DevTools 2.51.1

修正前の版を入れたサンプルでは、同じコマンドで 13.1.0、12.19.2、7.0.0 が表示されました。grep -A8 の数字は、名前の行から何行先まで読むかの指定です。Package.resolvedとpubspec.lockでは版の行が名前の5〜7行下にあるため、数字を小さくすると何も表示されません。

筆者のMacのDart 3.10.4は、修正版の3.13.7より古い版です。Android版のFlutterアプリを作り直すには、Flutterを3.47.8以降へ上げます。3.38から3.47へは大きく版が上がるので、flutter upgrade の前に、同じMacにあるほかのプロジェクトがビルドできるかや、Flutterの破壊的変更の一覧を確かめます。CIでビルドしている場合は、CIに入っているFlutterの版も同じように確かめます。

修正版で作り直したら、配り直して利用者に更新してもらう

Firebaseの案内は、SDKを上げるだけでは終わらないとしています。すでに利用者の端末に入っているアプリは古い仕組みのままなので、修正版で作り直したアプリを配り、利用者に更新してもらうところまでが対応です。

対応の手順

1. 版を確かめる

Package.resolved、Podfile.lock、pubspec.lock、手元とCIの flutter --version を見る。

2. 修正版で作り直す

表の修正版以降へ上げる。Unity・C++は作り直してリンクし直す。Podfileで古い版に固定していれば外す。

3. 配って更新を促す

ストアで新しい版を公開し、アプリ内のお知らせなどで利用者に更新を促す。

Firestoreを使うiOSアプリと、Flutterで作ったAndroidアプリの両方を持っている場合は、両方の版を確かめます。まずロックファイルとFlutterの版を見て、自分のアプリが表のどの行に当たるかを確かめると、作り直しが必要なアプリを洗い出せます。