eMudhra の証明書 8 枚が侵害、知っておくべきこと
2026 年 10 月 19 日、Cloudflare は eMudhra が発行した 8 枚の中間証明書が弱い鍵で作られていたことを把握した。誰でも任意ドメインの証明書を偽造できる状態だった。Cloudflare は自社インフラにパッチを当てクライアント更新を公開、記事は顧客と開発者が取るべき対策を挙げている。
日本語
コピー
2026 年 10 月 19 日 17:00 UTC ごろ、Cloudflare は 8 枚の eMudhra 中間証明書に関連する秘密鍵が漏洩していることを突き止めた。これらの証明書はブラウザや OS から広く信頼されており、Cloudflare 内部でも同様に信頼していた。鍵そのものの強度が不十分だったため、攻撃者は任意のドメインの証明書を偽造し、それを使ってサーバーになりすまし、通信を傍受したり改ざんしたりできる。インターネット全体に影響が及ぶ深刻なセキュリティインシデントである。SSL 証明書の仕組みと、それがインターネットの動作にとってなぜこれほど重要なのかについては、こちらに詳しい説明がある。
私たちはまず Cloudflare 内部の重要サービスを優先して修正し、脆弱性が公表される前に顧客を守れるようにした。セキュリティレビューの結果、Cloudflare のサービス上でこの問題が実際に悪用された形跡は見つかっていない。
Cloudflare One Clients（WARP または 1.1.1.1 アプリ）と Cloudflare Tunnel（cloudflared）のアップデートを公開し、CDN、Developer、Zero Trust の各製品ラインに緩和策を展開した。Gateway 経由で Cloudflare Zero Trust を利用していて、クライアントが最新版（下記参照）であれば、自動的に保護される。
私たちの対応
公開証明書を使ってリモートエンドポイントを認証するサービスを優先的に更新した。オリジンサーバーに接続するプロキシや、外部 API を呼び出すアプリケーションがこれに当たる。並行して、共有のトラストストア、ベースイメージ、その他の共有インフラも更新し、これらから証明書の信頼設定を継承するサービスには一律の緩和経路を用意した。更新後はリロード、再起動、イメージの再デプロイによって反映させている。独自のトラストストアを持つアプリやカスタムのトラストストアを使うアプリについては、個別に評価して更新した。これらの作業が対象としているのは証明書ベースの認証であり、TLS 暗号アルゴリズムそのものの弱点ではない。
Cloudflare の各チームは現在もさらなる修正を進めている。進展はあるが、やるべきことはまだ多い。一部の顧客は、自ら運用するソフトウェアや信頼設定、とりわけオリジンサーバー上の設定について対応が必要になる。 推奨する対応を以下にまとめる。
顧客が取るべき対応
| 対象のソフトウェアまたはサービスの利用者 | 顧客が取るべき操作 |
|---|---|
| Cloudflare One/WARP | Cloudflare One Client：v2.5.6（Android）、v1.12.16（iOS）、Windows デスクトップ版（2026.8.2115.0）、macOS（2026.8.2115.0）、Linux（2026.8.2115.0）にアップグレード。1.1.1.1 アプリ：v6.38.10（Android）、v6.31.7（iOS）、Windows デスクトップ版（2026.8.2115.0）、macOS（2026.8.2115.0）、Linux（2026.8.2115.0）にアップグレード |
| Cloudflare Tunnel（cloudflared） | 2026.10.2 にアップグレード。コンテナで運用している場合は、修正済みイメージに更新して再デプロイする |
| 顧客が自ら設定する TLS クライアント認証 | クライアント証明書の検証に使っている相互 TLS のトラストストア、またはアップロード済みの CA を確認して更新する |
| 顧客のオリジンサーバー側 TLS 設定 | Full (strict)またはStrict暗号化モードを使っている場合は、カスタムのオリジン証明書とサーバー設定を確認する。Automatic SSL/TLSを更新中で、こうした信頼されない証明書を使い続けていると自動で通知されるようになる。該当する証明書はサービス停止につながる。 |
| Cloudflare Containers | Cloudflare Containers（Sandboxes を含む）を使っている顧客は、コンテナイメージとアプリケーションの依存関係にある影響を受けた証明書トラストストアを確認し、デプロイ済みのイメージに合わせて更新する。HTTPS 送信インターセプトを有効にすれば、送信 HTTPS リクエストが Cloudflare 経由で転送され、リモートサーバー証明書の検証をアプリケーションから Cloudflare が管理するインフラへ移せる。これにより、インターセプトされた接続は Cloudflare のトラストストア緩和策で保護される。この機能を有効にしているコンテナはすでに保護されている。 |
開発者向けの指針
開発者は SDK の下層まで目を向けてほしい。
API クライアントは証明書の検証を HTTP ライブラリ、言語ランタイム、OS、あるいは独自の信頼設定に委ねていることがある。SDK だけを更新しても、下層のポリシーが変わるとは限らない。
パッチを適用した後、ダッシュボードに証明書エラーが表示されることがある。重要なのは、そのエラーを検証を無効にして解消しないことだ。 それをすると、今回の更新で取り戻そうとしている認証の保護そのものを失う。
今回のインシデントは、WebPKI による本人確認に依存する多くのソフトウェアスタックに影響している。Mozilla の Dennis Jackson が、修正済みのよく使われるパッケージの一覧をクラウドソーシングでまとめている。早めにアップグレードすることを勧める。（いくつかは自分のスタックの間接的な依存関係である可能性があるので、依存ツリーを確認すること。）関連する依存関係を更新し、影響を受けるイメージを再ビルドし、アプリケーションのリロード、再起動、再デプロイが必要かどうかを確認してほしい。
Dennis Jackson のテストサイトでは、ブラウザでの検証、ブラウザ以外の環境でのテスト手順、パッケージ更新情報を提供している。結果が妥当なのは、テストしたその検証経路に限られる。デバイス上のすべてのアプリが問題ないことを示すものではない。検証はアプリが実際に使う TLS 経路で行うこと。ブラウザのテストが通っても、バックエンドサービスまで保護されている証明にはならない。アプリが別のバリデータを使っているなら、curl でのテストも同じく当てにならない。
タイムライン
現時点までの経緯は次のとおり。
| 日時 | 出来事 |
|---|---|
| 10 月 19 日 約 17:00 UTC | Cloudflare が侵害を検知し、評価を開始。 |
| 10 月 20 日 02:00 UTC | Cloudflare One Client と WARP アプリのセキュリティ更新を各プラットフォームでリリース（iOS 版 Cloudflare One Agent を除く。アプリ審査が進行中）。 |
| 10 月 20 日 09:15 UTC | Cloudflare Tunnel（cloudflared）のセキュリティ更新をリリース。 |
| 10 月 20 日 19:20 UTC | CDN とサーバー側 Zero Trust の緩和策を全面展開完了。 |
今後
今回の影響は一様ではない。ブラウザベンダーはスイッチをひとつ切り替えるだけで直せる。もちろん、彼らが更新すべきアプリは何百もではなくひとつだけだ。だが彼らには有効な手がひとつある。ほとんどのブラウザが採用している迅速な失効の仕組み（Chrome の CRLSets など）だ。Cloudflare でも一部の製品で同種の仕組みを使っている。Cloudflare 内部や業界全体でもっと多くのシステムにこれを広めるため、私たちは upki のようなプロジェクトに期待している。トラストストアは静的なルート認証局のリストであってはならず、失効情報や Certificate Transparency の鍵などを素早く更新できるものでなければならない——彼らはそれを理解している。