Flutter と Firebase を使うアプリの開発者にも、2026年10月の認証局 eMudhra の中間CA侵害への対応が求められました。やることは、Android/Windows/Linux 向けの Flutter アプリは Dart 3.13.7 以上（または Flutter 3.47.8 以上）へ、Cloud Firestore を使うなら cloud_firestore 7.1.0 以上（FlutterFire BoM 5.1.0 以上。7.x に上げられないなら iOS/macOS は 6.10.1、Windows は 6.10.2 のバックポート）へ上げて、再ビルドして配り直すことです。なぜ版が環境ごとに違うのか、なぜ端末のOS更新だけでは直らないのかを、Firebase 公式の remediation guide と Dart の勧告で裏を取って整理します。1社の鍵の弱さがなぜ各言語・各ランタイムに一斉に波及したのかという全体像は、eMudhra とは？ 1社の鍵の弱さがGo・Java・Pythonに波及した仕組みをわかりやすく解説にまとめています。依存の取得やアプリの配布経路そのものが攻撃の入口になりうる全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説に整理しています。

WHAT HAPPENED時系列

eMudhra の中間CA侵害が、Flutter と Firebaseに及んだ流れ

  1. 10/19

    Google が eMudhra 中間CAの侵害を把握

    弱い鍵の8つの中間CAが復元されうると公開。Google が各製品にパッチを配り始める

  2. 10/22

    Firebase Apple SDK 12.19.3 を公開

    iOS/macOS の Cloud Firestore が埋め込みで信頼していた eMudhra 由来のルートを信頼ストアから除去

  3. 10/23

    FlutterFire が修正版の cloud_firestore を公開

    主修正は 7.1.0（BoM 5.1.0・iOS/macOS/Windows 共通）。7.x 据え置き向けに 6.10.1（iOS/macOS）・6.10.2（Windows）

  4. 10/23

    Dart の勧告 GHSA-frr6-h895-5pxp を公開

    dart:io の BoringSSL が OS のブロックリストを読まず eMudhra を信頼。修正は Dart 3.13.7／Flutter 3.47.8

  5. 10/23

    Windows Firestore の C++ SDK 13.13.1 を公開

    firebase_core の後続版で Flutter からも対応

出典: Firebase 公式 remediation guide、Dart GHSA-frr6-h895-5pxp、pub.dev（cloud_firestore）、各リリース（2026-10-27 確認）

30秒でわかる

  • ・何が起きたか：eMudhra の中間CAの秘密鍵が弱く復元できた。偽のHTTPS証明書を作れる状態になり、通信に割り込める相手に偽サーバーを本物と誤認させうる
  • ・Flutter の急所：dart:io の BoringSSL が OS のブロックリストを読まず、自前で eMudhra を信頼していた。Android/Windows/Linux が対象（Web/iOS/macOS は Dart 側では非対象）
  • ・Firebase の急所：Cloud Firestore が gRPC 用のルート証明書を自前で持つ。そこに eMudhra 由来のルートが残っていた
  • ・対応：Android/Windows/Linux は Dart 3.13.7／Flutter 3.47.8 以上、Cloud Firestore は cloud_firestore 7.1.0 以上（6.x 据え置きなら iOS/macOS 6.10.1・Windows 6.10.2）。上げたら再ビルドして再配布

まず手元が対象かを確かめます。ターミナルで flutter --version と dart --version を実行し、Flutter が 3.47.8 未満、または Dart が 3.13.7 未満なら Android/Windows/Linux 向けビルドは対象です。これは侵害されたかの判定ではなく、修正の入っていない版でビルドしているかの確認です。

いつ、何が起きたのか

発端は、インドの認証局 eMudhra（ブランド名 emSign）が発行に使っていた中間CAの秘密鍵が、当て推量で復元できるほど弱かったことです。Google は2026年10月19日にこの侵害を把握したと公表し、自社の製品群へ順にパッチを配りました。ブラウザやOSの対応は早く進みましたが、Flutter や Firebase のように自前で証明書の信頼リストを持つ仕組みは、それぞれ別に直す必要がありました。

中間CA とは、ブラウザやOSが最初から信頼している「ルート認証局」と、実際のサイトの証明書の間に立つ中継ぎの認証局です。中間CAの鍵が弱いと、その鍵を復元した相手が「任意のドメイン向けの本物に見える証明書」を自分で作れます。これを悪用できるのは、被害者とサーバーの間に割り込める位置（公衆Wi-Fi・ISP・経路上）にいる相手です。現時点で、今回の鍵を使った実際の悪用は報告されていません。

Flutter・Firebase に関する一次情報の主な時点は次の通りです。

・10/22：iOS/macOS 向けの Firebase Apple SDK 12.19.3 が公開。Cloud Firestore が埋め込みで信頼していた eMudhra 由来のルートを信頼ストアから除去
・10/23：FlutterFire が修正版の cloud_firestore を公開。主たる修正は 7.1.0（FlutterFire BoM 5.1.0 以上・iOS/macOS/Windows 共通）、6.x 据え置き向けに 6.10.1（iOS/macOS）・6.10.2（Windows）
・10/23：Dart の勧告 GHSA-frr6-h895-5pxp が公開。修正は Dart 3.13.7／Flutter 3.47.8
・10/23：Windows の Firestore が使う C++ SDK 13.13.1 が公開

これは当サイトで扱った Go 脆弱性 CVE-2026-111943｜x509がeMudhraの中間CA 8件を拒否、作り直しと確認手順 や Java（CVE-2026-91403）と同じ根の事案の、Flutter・Firebase 側の現れ方です。

なぜ Flutter と Firebase が影響を受けるのか

HTTPS の正しさは、通信する側が持つ「信頼する認証局の一覧（トラストストア）」で判断します。問題は、Flutter と Firebase がこの一覧をOS任せにせず、自前で持っていたことです。

Flutter 側の急所は Dart の dart:io です。Dart の勧告 GHSA-frr6-h895-5pxp によれば、dart:io は自分にコンパイルして組み込んだ BoringSSL で TLS を検証していて、OS が管理する中間CAのブロックリストを読みませんでした。そのため、OSが eMudhra を失効させても、Dart/Flutter でビルドしたバイナリは eMudhra を信頼し続けます。勧告が対象とするのは Android・Windows・Linux（Linux は未パッチ環境やコンテナ環境に限る）で、Web・iOS・macOS は対象外です。iOS/macOS はプラットフォーム側の TLS を使うためです。

Firebase 側の急所は Cloud Firestore です。Firestore は内部で gRPC を使って通信し、そのルート証明書の束をSDKに埋め込んで持っています。この束に eMudhra 由来のルートが残っていたため、OS や Dart を直しても Firestore の経路は別に塞ぐ必要がありました。Firebase Apple SDK 12.19.3 が、この埋め込みの束から eMudhra 関連のルートを除いた修正です。FlutterFire はこれに対応した cloud_firestore を配りました。主たる修正は 7.1.0（FlutterFire BoM 5.1.0 以上）で、iOS・macOS・Windows に共通します。7.x にまだ上げられないプロジェクト向けに、6.x 系のバックポート（iOS/macOS は 6.10.1、Windows は 6.10.2）も用意されています。

WHAT TO UPGRADEプラットフォーム別の修正版

どの環境を、どの版へ上げるか

  1. 1.Flutter アプリ（Android / Windows / Linux）

    Dart 3.13.7 以上、または Flutter 3.47.8 以上（＋Dart 3.13.7 以上）。ツールチェーン側の修正

  2. 2.Cloud Firestore（iOS / macOS / Windows 共通）

    cloud_firestore 7.1.0 以上（FlutterFire BoM 5.1.0 以上）が主たる修正

  3. 3.最新メジャーに上げられない場合のバックポート

    iOS/macOS は 6.10.1（BoM 4.20.1）、Windows は 6.10.2（BoM 4.20.2）。素の Apple ネイティブは Firebase Apple SDK 13.1.1 以上または 12.19.3

  4. 4.Android の Firebase App Distribution Gradle プラグイン

    5.3.1 以上。再ビルド・再配布は不要（プラグイン更新と CI/CD 反映のみ）

出典: Firebase 公式 remediation guide、Dart GHSA、pub.dev（cloud_firestore）、firebase-ios-sdk / firebase-cpp-sdk のタグ（2026-10-27 確認）

どのプラットフォームを、どの版へ上げるか

Flutter eMudhra 対応、そして Firebase eMudhra 対応で迷いやすいのは、修正の出どころがプラットフォームごとに違うことです。Dart ツールチェーンの修正で済むものと、Firebase SDK の更新が要るものが混ざります。次の表が対応の全体像です。最後の Firebase App Distribution を除くすべての行で、上げたら再ビルドして再配布することが要ります。

対象 直すもの 修正版
Flutter アプリ（Android / Windows / Linux） Dart / Flutter ツールチェーン Dart 3.13.7 以上、または Flutter 3.47.8 以上（＋Dart 3.13.7 以上）
Cloud Firestore（iOS / macOS / Windows・FlutterFire） cloud_firestore プラグイン cloud_firestore 7.1.0 以上（FlutterFire BoM 5.1.0 以上）＝主たる修正・3プラットフォーム共通
同上で最新メジャーに上げられない場合のバックポート cloud_firestore プラグイン（土台は C++ SDK 13.13.1） iOS/macOS は 6.10.1（BoM 4.20.1）、Windows は 6.10.2（BoM 4.20.2）
Cloud Firestore（Apple ネイティブ） Firebase Apple SDK 13.1.1 以上、または 12.19.3
Android の Firebase App Distribution Gradle プラグイン 5.3.1 以上（再ビルド・再配布は不要。プラグイン更新と CI/CD 反映のみ）

表の版は Dart の勧告 GHSA-frr6-h895-5pxp、Firebase 公式の remediation guide（日本語版・原文照合済み）、pub.dev（cloud_firestore）で確かめたものです。最終行の Firebase App Distribution だけは、他の全ケースと違ってアプリの再配布が要りません（後述）。

公式の remediation guide は、Cloud Firestore を使う Flutter アプリの主たる修正として cloud_firestore 7.1.0 以上（FlutterFire BoM 5.1.0 以上）を挙げています。これは iOS・macOS・Windows に共通する修正です。最新メジャーにまだ上げていないアプリ向けに、前メジャーの新しいパッチ版へ修正をバックポートしたものが 6.x 系で、iOS/macOS は 6.10.1（BoM 4.20.1）、Windows は 6.10.2（BoM 4.20.2）です。影響を受けるのは 7.0.0 以前（6.10.1 と 6.10.2 を除く）です。

OSを更新しても、配布済みのアプリは直らない

今回のいちばんの落とし穴は、端末のOSを最新にしても、すでに配布したアプリは直らないことです。Flutter の BoringSSL も Firestore のルート証明書の束も、ビルドしたときにアプリのバイナリへ組み込まれるからです。利用者が自分のスマホを最新のOSにしても、インストール済みの古いビルドは古い信頼リストをそのまま抱えています。

WHY REBUILD誤解と実態

OSを更新しても、配布済みのアプリは直らない

こう思いがち

実際は

こう思いがち: 端末のOSを最新にすれば利用者のアプリも直る

実際は: TLSの検証に使う証明書はアプリのバイナリに埋め込まれる。OS更新だけでは配布済みビルドは古い信頼のまま

こう思いがち: SDKを上げればすぐ全利用者が安全になる

実際は: 開発者がSDKを上げて再ビルドし、ストア／配布基盤へ出し直す。利用者がアプリを更新して初めて直る

こう思いがち: Firebase プラグインを1つ上げれば足りる

実際は: Android/Windows/Linux はツールチェーン、iOS/macOS/Windows の Firestore はSDKと、修正の出どころが別。環境ごとに上げ切る

出典: Firebase 公式 remediation guide（修正はアプリの再ビルド・再配布で初めて利用者に届く、2026-10-27 確認）

直すには、開発者が次を順に行う必要があります。

・SDK・ツールチェーンを表の版へ上げる（flutter upgrade、flutter pub upgrade）
・該当プラットフォーム向けに再ビルドする
・ストアや Firebase App Distribution などの配布基盤へ出し直す
・利用者にアプリ更新を促す（強制更新の仕組みがあれば併用する）

これは、OSの証明書を直しても pip 本体が直らず pip を上げ直す必要があった pip をいますぐ26.2.2へ更新｜認証局eMudhraの弱い鍵と、OSの証明書を直しても pip が直らない理由 と、まったく同じ構図のモバイル版です。

自分のアプリを確認する

手元のプロジェクトが対象の版でビルドしているかを確かめます。いずれも侵害されたかの判定ではなく、修正の入った版を使っているかの確認です。重いディスク全体の検索は不要です。

ツールチェーンの版を見ます。

flutter --version
dart --version

Flutter が 3.47.8 未満、または Dart が 3.13.7 未満なら、Android/Windows/Linux 向けビルドは対象です。flutter upgrade で安定版へ上げます。

Firestore を使うなら、プロジェクトのプラグイン版を見ます。

flutter pub deps | grep cloud_firestore

cloud_firestore が 7.1.0 未満なら上げます（iOS・macOS・Windows 共通の主たる修正）。7.x にまだ上げられない場合は、iOS/macOS は 6.10.1、Windows は 6.10.2 のバックポートでも塞げます。pubspec.yaml の制約を直して flutter pub upgrade で反映させ、iOS のネイティブ依存は ios/Podfile.lock で Firebase/Firestore 系の版を確認します（Firebase Apple SDK が 12.19.3 または 13.1.1 以上か）。

これらは「いま侵害を受けているか」を調べるコマンドではありません。問題は証明書の信頼リストの中身なので、ファイルの有無では判定できません。確認できるのは「修正の入った版でビルドしているか」だけです。版が古ければ上げて再ビルドし、新しければ追加の作業は要りません。上げ終えたら、必ず再ビルドして配布し直します。

影響範囲とつながらなくなる相手

修正版で再ビルドすると、eMudhra の問題の中間CAから発行された証明書を使う相手とは、TLSでつながらなくなります。これは安全側の挙動ですが、取引先のAPIや社内のサーバーがその中間CAの証明書を使っていると、更新後に接続エラーになる可能性があります。更新を一斉に出す前に、接続先のうち eMudhra（emSign）系の証明書を使っているものがないかを洗い出しておくと、障害を避けられます。

なお Cloud Firestore のバックエンドそのものや Firebase App Distribution のバックエンドは影響を受けません。問題はアプリに焼き込まれた信頼リストの中身であって、サーバー側ではないからです。そのため Firebase App Distribution の Gradle プラグインだけは例外で、プラグインを 5.3.1 以上へ上げて CI/CD に反映すれば済み、アプリの再ビルド・再配布は要りません。残りのすべてのケースは、SDK やツールチェーンを上げたうえで再ビルドして配り直す必要があります。

便乗した偽の注意喚起にも注意してください。更新はストアと公式のパッケージ配布経路から行い、メールやSNSのリンク先で勧められた手順をそのまま実行しないことです。やることは派手ではなく、環境の数だけ版を上げ切り、再ビルドして配り直すことに尽きます。それで今回の余地は塞げます。

参照ソース