firebase-ios-sdkの証明書問題でFirestore通信がMITMの恐れ｜13.1.1/12.19.3へ更新

Firebase の Apple/iOS SDK（Cloud Firestore）に、侵害された認証局（CA）に由来するルート証明書が埋め込まれていたことがわかり、2026-10-22 に修正版 firebase-ios-sdk 13.1.1 と 12.19.3 が公開された。古い SDK のままだと、Firestore との通信を中間者に盗み見られる恐れがある。攻撃は不正アクセスというより「信頼してはいけない証明書を SDK が信頼し続けてしまう」問題で、対策はライブラリを更新して、新しいビルドをユーザーに再配信することだ。この記事は、何が起きたか・対象と対象外・自分のアプリの確かめ方を、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 の文脈も踏まえて一次情報で整理する。

今すぐ確かめるなら、お使いのロックファイルで現在の版を見る（詳細は後半「自分のアプリを確認する」）。

git fetch --all --prune
# CocoaPods を使っている場合（Podfile.lock に版が載る）
grep -nE "FirebaseFirestore|firebase-ios-sdk" Podfile.lock
# Swift Package Manager を使っている場合（Package.resolved に版が載る）
grep -rnE "firebase-ios-sdk" -A5 --include=Package.resolved .

何が起きたか——侵害されたCAと埋め込み証明書

firebase-ios-sdk（Apple 向け）は、Firestore への接続を検証するためのルート証明書を SDK 内に同梱している（埋め込み trust store）。OS 標準の信頼ストアに任せきりにせず、SDK 側で接続先の正当性を確かめるための仕組みだ。今回の問題は、その埋め込み trust store の中に、侵害された eMudhra 中間CA に連なるルート証明書が含まれていたことにある。

侵害された CA が発行した「本物に見える偽の証明書」を SDK が信頼してしまうと、攻撃者は Firestore との通信路に割り込み、暗号化されているはずの中身を復号して盗み見ることができてしまう（中間者攻撃＝MITM）。修正版はこの該当ルート証明書を埋め込み trust store から削除し、危険な信頼を外した——GitHub のリリースノートでは「Cloud Firestore security update to protect client connections against a compromised certificate authority」、Firestore の CHANGELOG では「Removed compromised eMudhra intermediate CA root certificates from embedded trust store」と記されている（PR #16930 / #16933）。

そもそも、なぜ SDK が証明書を同梱するのか。OS 任せにしない分、接続先を厳しく絞れる利点がある一方で、CA 侵害のように「信頼の前提」が崩れたときは、同梱している側がビルドを配り直さないと直せないという裏返しのコストがある。今回はその後者が顕在化した形だ。これは Firebase 固有というより、証明書を固定して運用する（ピンニング）全般に共通する「更新運用の宿題」でもある——固定するなら、固定したものが腐ったときの配り直しまでを設計に含めておく必要がある。

影響するSDK・しないSDK

Google の通知メールによれば、影響範囲はプラットフォームで分かれる。要点は「Apple ネイティブ層を使う経路は対象、それ以外は対象外」だ。

Flutter・C++・Unity・React Native Firebase が対象に入るのは、これらが iOS 上では内部で Apple ネイティブの Firestore 実装を使うためだ。逆に、Android・Web・サーバーサイドは別の経路でバックエンドにつながるため、今回の埋め込み証明書の問題の外にある。Cloud Firestore のバックエンドサービス自体は影響を受けないので、サーバー側で直す作業は不要だ。

対策——どの版へ更新すればよいか

やることは「firebase-ios-sdk を修正版へ上げて、アプリを再ビルドして再配信する」。使っている Firebase のメジャー系で版が分かれる。

# CocoaPods（Podfile）: 13系へ上げる例
pod 'Firebase/Firestore', '~> 13.1'
# 反映: pod update FirebaseFirestore

Swift Package Manager なら、Xcode の Package Dependencies で firebase-ios-sdk のバージョン規則を 13.1.1 以上（または 12.19.3）に引き上げ、Package.resolved を更新する。ライブラリを上げただけでは対策は完了しない——エンドユーザーの端末に新しいビルドが届いて初めて、危険な証明書を信頼しない状態になる。App Store の審査・配信のリードタイムを見込んで、早めに更新版を出すのがよい。

自分のアプリを確認する

まず最新を取り込み、ロックファイルで現在の版を確かめる。git fetch を先に走らせるのは、手元が古いまま判断しないためだ。

git fetch --all --prune

# CocoaPods: Podfile.lock に "FirebaseFirestore (x.y.z)" の形で載る
grep -nE "FirebaseFirestore|firebase-ios-sdk" Podfile.lock

# Swift Package Manager: Package.resolved に firebase-ios-sdk の version が載る
grep -rnE "firebase-ios-sdk" -A5 --include=Package.resolved .

表示された版が 13.1.1 未満（12 系なら 12.19.3 未満）なら更新が必要だ。Flutter は pubspec.lock、React Native Firebase は iOS 側の Podfile.lock、Unity は使用している Firebase Unity SDK の版を確認する。見つからない・判断がつかないときは、Firebase を Firestore 用途で使っていないか、別経路で入っている可能性があるので、依存の入れ方から棚卸しする。

なお、この確認でわかるのは「いま依存している版」だけだ。版を新しくしても、古いビルドがユーザーの端末に残っていれば安全とは言えないし、過去に実際に盗み見られたかどうかを判定するものでもない。あくまで「更新が要るかどうか」を切り分けるための確認である。こうした依存の更新を通知頼みにしないために、Renovate・Dependabotでサプライチェーン更新に自動追従する 仕組みや、脆弱性の検知をCIに組み込む 運用を併せておくと、次に同種の更新が来たときの取りこぼしが減る。

なぜ「更新して再配信」まで必要か——影響範囲

今回の対策が「ライブラリ更新」で終わらないのは、危険な証明書がユーザーの端末上のアプリ（＝配布済みビルド）に埋め込まれているからだ。あなたのリポジトリで版を上げても、すでにインストールされているアプリは古い trust store を持ったまま動く。だから、更新版をビルドしてストア経由で配り直すところまでが対策になる。

影響の広がりを冷静に見ると、(1) 盗み見られうるのは Firestore との通信路で、(2) 成立には「侵害された CA で発行された偽証明書を使って通信路に割り込める」状況が要る。とはいえ、CA 侵害を前提にした MITM は公共 Wi‑Fi などで現実味があり、ベンダーが緊急のセキュリティ更新として出した以上、先送りする理由はない。Star 数や派手さではなく「自分のアプリがどの SDK 経由で Firestore に触れているか」を基準に、対象なら淡々と上げる——それが今回の正しい動きだ。

参照ソース

• firebase-ios-sdk 13.1.1 リリース（GitHub）（「compromised certificate authority」「eMudhra」の一次記述・2026-10-22）
• firebase-ios-sdk 12.19.3 リリース（GitHub）（Firebase 12 系・CocoaPods 向け）
• Firestore CHANGELOG（firebase-ios-sdk）（「Removed compromised eMudhra intermediate CA root certificates from embedded trust store」）
• Firebase Apple SDK リリースノート（公式）（版ごとの公式ノート。最新は公式で確認）
• Google からの開発者向け通知メール（ユーザー提供・影響プラットフォームの区分の出典）