eMudhra CAの侵害：Chromeが10月27日にemSign ECC Root CA - G3を削除

要点

• Wayneという名の研究者は2026年10月17日、eMudhraの8つの中間CA証明書の秘密鍵を誰でも公開証明書から計算できると示し、復元した各鍵でメッセージに署名して証明しました。eMudhraは原因を2025年4月30日の鍵生成セレモニーにおける欠陥のある鍵ラップ処理としています。8つの値はすべて256未満の整数で、Scott Helmeは自身のノートPCで1秒未満ですべてを復元しました。
• 中間CA鍵を持つ者は任意のドメインに有効な証明書を発行でき、その鍵を信頼するクライアントに対し、検出できないWebサイトやサービスのなりすましが可能になります。Chrome（CRLSets）とFirefox（OneCRL）は10月17日、Appleはアドバイザリによれば10月19日から、Microsoftは10月20日に中間CAをブロックしました。6つのTLS中間CAからの証明書はCertificate Transparencyに一度も記録されていなかったため、CTを強制するブラウザーには届いていません。
• 危険にさらされるのはCTを強制せず失効情報も取り込まないすべてのクライアントです。curlなどのコマンドラインツール、独自CAバンドルを持つ言語ランタイムやアプリケーション、未修正ElectronでビルドされたSlackやDiscordなどのElectronアプリケーション、IoTや組み込みデバイスが該当します。Go、Node.js、Python、certifi、Electron、主要ディストリビューション、多くのベンダーが更新または鍵拒否リストを提供しています。
• 証明書がemSign ECC Root CA - G3につながるWebサイトを運営している場合、ChromeはRoot Storeバージョン43でそのルートを削除し、太平洋時間10月27日朝にデバイスへ届きます。Googleは別の階層の証明書を直ちに取得してインストールするよう指示しています。約30,800の未失効証明書がこのルートにつながり、その99.9パーセントはInCommon経由で発行されています。

影響を受けますか？

影響を受けるのは2つのグループです。CTと失効確認なしでemSign ECC Root CA - G3または侵害された中間CAをまだ信頼するクライアントと、証明書がそのルートにつながるサイト運営者です。両方を確認してください。

Certificate Transparency（CT）は、発行済みTLS証明書を記録する公開の追記専用ログの仕組みです。CTを強制するブラウザーは、証明書がログに記録された証拠を持つ場合にのみ信頼します。

クライアントとして（接続を傍受される可能性があるか）、次をすべて満たす場合に影響を受けます。

• ソフトウェアが、emSign ECC Root CA - G3をまだ含む、または侵害された中間CAを受け入れるシステムもしくは同梱の信頼ストアでTLSを検証する。
• Certificate Transparencyを強制しない。ブラウザー（Chrome、Edge、Firefox、Safari）は除外されますが、curl、大半の言語ランタイム、大半のElectronアプリ、大半の組み込みクライアントは除外されません。
• すでにブラウザーを保護している配信済み失効ブロック（OneCRL、CRLite、CRLSets）を取り込まない。

インシデントサイトが公開した確認用ホストでクライアントを直接テストしてください。証明書エラーなら保護されています。接続に成功したら、侵害された中間CAをまだ信頼しています。「noct」ホストでも成功するならCTを強制していないことも意味します。

curl自体はCertificate Transparencyを確認しないため、チェーンを信頼していれば「noct」ホストへの接続は成功します。CT強制をテストするには、確認したいクライアントから接続してください。

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/        # chain without SCTs; curl does not check CT
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

サーバー運営者として（サイトが動かなくなるか）、提供するいずれかの証明書がemSign ECC Root CA - G3につながれば影響を受けます。ChromeのCTログ集計によると、10月21日時点で約30,800の未失効証明書が該当しました。99.9パーセントは、Internet2が高等教育向けに運営する証明書サービスInCommonを通じて発行されています。InCommonは2026年4月から7月の間にeMudhraのCertiNextプラットフォームへ移行しました。

これらのCVEのうち2つには、割り当てた組織によるCVSSスコアがあります。CVE-2026-115557は9.4 Critical（CVSS 4.0、Python Software Foundation）、CVE-2026-114820は9.1 Critical（CVSS 3.1、Oracle）です。GoのCVE-2026-111943レコードにはスコアがありません。MozillaもCVE-2026-113470（Firefox）には付けていませんが、CISAによる補足評価は5.4 Medium（CVSS 3.1）です。

インシデントサイトはほかにも数十件を追跡しています。Bun 1.4.4、Deno 2.9.8、Docker Desktop 4.96.2、Git for Windows 2.56.0.3、VS Code 1.143.1、GitHub CLI 2.102.1、conda 26.9.4、pip 26.2.2、mitmproxy 12.3などで、10月27日時点ではLibreOffice、Godot、certbot、containerdが対応待ちです。

独自にNodeを同梱するツールは、修正済みランタイムへ移行した場合だけ修正を引き継ぎます。mongosh 2.14.0未満はホストNodeランタイムの信頼ストアで検証しますが、2026年10月23日リリースの2.14.0は鍵ブロックリストを含むNode 24.22.1を同梱します。

どう修復しますか？

すべてのブラウザーとブラウザー以外のクライアントにパッチを適用し、emSign ECC Root CA - G3につながる証明書を10月27日までに置換してください。クライアント運用者は次の順に更新します。

1. ブラウザーとOSは自動更新しますが、最新か確認してください。ブロックはChromeのCRLSets（10月17日）、FirefoxのOneCRL（10月17日）、AndroidのGoogle Play services（10月19日）、Appleの自動信頼リスト更新（アドバイザリによれば10月19日から）、Microsoftの自動信頼リスト更新（10月20日）を通じて届きました。

2. 表にあるブラウザー以外のクライアントをすべて修正します。

   • Go：1.27.3または1.26.10でバイナリを再ビルドします。
   • Node.js：ランタイムと、それを同梱するアプリケーションを更新します。
   • Python：sslモジュールがCVE-2026-115557の拒否リストを初めて含む3.15.2、3.14.10、3.13.18、3.12.16、3.11.18へ更新するか、certifiを2026.10.19以降に固定します。
   • Java：Azulの定例外ビルド、または鍵をブロックする別のJDKへ更新します。
   • Electron：42.11.16以降でアプリを再ビルドします。

   注意：10月21日のPythonリリース3.15.1、3.14.9、3.13.17には拒否リストがありません。certifi 2026.10.19を組み込むpip 26.2.2を同梱しますが、保護するのはpip自身の操作だけです。

3. ディストリビューションでは更新済みca-certificatesパッケージをインストールします。パッケージが待機中だったRHEL 7では、Red Hatが文書化した信頼ストアのブロックリスト回避策を適用します。

特にmacOSでは、コマンドラインのcurl、git、組み込みPythonは、失効を確認せず/etc/ssl/cert.pemで検証します。Appleアドバイザリ149555は、プラットフォームが10月19日から12の中間証明書、10月23日からルートをブロックしているとし、これらのコマンドラインツールが確認する/etc/ssl/cert.pemの修正は「今後のソフトウェア更新で利用可能になる」としています。

それまでは、インシデントサイトが公開する削除スクリプトで、そのファイルからemSign ECC Root CA - G3を削除してください。第2の手順では、6つのクロス署名コピーをブロックするためSectigoのAAA Certificate Servicesルートも削除します。AAAの削除は無関係なサイトを壊す場合があり、macOS更新がファイルを元に戻す可能性があると警告しています。

emSign ECC Root CA - G3配下の証明書を持つWebサイト運営者に回避策はありません。Google Chrome Root Programは、太平洋時間10月27日朝にルート削除がデバイスへ届く前に、「Chrome Root Storeに含まれる別のPKI階層から新しいTLS証明書を直ちに取得してインストールしなければならない」と指示しています。

Chromeは、標準のACMEクライアントはACME Renewal Information（ARI）対応か手動介入がなければ、更新期間外に証明書を置換しないとも警告しています。eMudhraは約30,000の証明書の移行が必要で、約97パーセントがACME発行と推定しています。大学からは実用的な経路が報告されました。影響のないeMudhra G1ルート配下のInCommon RSA証明書は現在も動作し、Let's Encryptが一般的な代替です。

根本原因は何ですか？

中間CAの秘密鍵は予測不能な乱数でなければなりません。eMudhraの鍵生成セレモニーは、意図した強い鍵と並んで、公開証明書自体から判明するほど予測しやすい第2の組を生成しました。

8つの中間CAは、TLS用6つ（G3BとG3CのEM DV、EM OV、EM EV TLS CA）とコード署名用2つ（EM OV CS CA G3BとG3C）です。2025年4月30日の鍵生成セレモニーで、FIPS 140-2 Level 3認定のハードウェアセキュリティモジュール上で、emSign ECC Root CA - G3配下に作成されました。

インシデント声明でeMudhraは、「鍵のラップ／アンラップ工程が、元の強い鍵と並んで第2の弱い鍵の組を生成した」と説明しました。鍵ラップは転送のために鍵を包装し、アンラップはそれを再び取り出す処理です。同社は「ブラウザーのルートストアに公開されたのは弱い鍵の方だった」と付け加えました。

インシデントサイトは結果を明確に述べています。「中間証明書の秘密鍵はCAによって誤って生成されました。つまり、誰でも証明書からそれを復元できます。」Scott Helmeはこれを実際に検証し、ノートPC上で公開証明書から8つすべての鍵を1秒未満で復元しました。

8つの値の1つは数字の4で、残りも256未満の整数です。

その後、事態を悪化させる事実が2つ明らかになりました。

2025年、eMudhraは同じ中間CAのうち6つについて無効なCRLを公開し、「各中間CAに関連付けられた適切な秘密鍵を使ってCRLを再生成」して修正したと報告していました。2026年10月19日、同社はMozillaに、それらのリストは実際には同じ弱い鍵、つまり「欠陥のある鍵で再署名」されていたと説明しました。Chromeはこれが「eMudhraの透明性とインシデント対応に深刻な懸念を生む」と述べています。

2026年10月14日、eMudhraはemSign Root TLS CA - G1のCRLを公開しましたが、その署名は当該CAの鍵では検証できません。Mozillaのバグ報告参加者はOCSP証明書の鍵で署名されたものと評価し、「別の弱い鍵の証拠ではなく、誤った署名鍵を使った事例」としました。

10月22日時点で、eMudhraはこれらに関するChromeの12の質問に回答していませんでした。

どのように悪用されますか？

悪用は機械的です。公開証明書から8つの秘密鍵の1つを再計算し、対象ドメインの末端証明書を偽造し、CTと失効確認を省略するクライアントの接続を傍受します。実環境での悪用は観測されていません。影響を受けるクライアントへの攻撃経路は次のとおりです。

1. 攻撃者は公開された中間証明書から8つの秘密鍵の1つを計算します。ノートPCで1秒未満の手順です。
2. 攻撃者は、なりすましたい任意のドメインに対して、その中間CAで署名した証明書を発行します。そして不正アクセスポイント、BGPやDNSの傍受、悪意あるイントラネットホストなど、被害者の接続を傍受または応答できる位置から提供します。
3. 被害者のクライアントは、偽造末端証明書から中間CAを通り、信頼するルートまでのチェーンを構築します。バンドル内のemSign ECC Root CA - G3、または中間CAのクロス署名コピー経由のSectigo AAA Certificate Servicesです。
4. クライアントがCertificate Transparencyを強制せず、失効ブロックや更新済みバンドルを受け取っていなければ接続は受け入れられます。CTを強制すれば攻撃者は偽造証明書を公開ログへ記録する必要があり、発見され得ます。ブラウザーは悪用成立に必要な両条件を満たさず、安全です。大半のコマンドラインツール、同梱ランタイム、組み込みクライアントは歴史的に両方の保護を欠き、修正まで危険にさらされていました。

決定的な緩和要因は、ブロック適用前に6つのTLS中間CAにつながる証明書がCertificate Transparencyへ一度も記録されなかったことです。CTを強制するブラウザーはログ記録済み証明書を要求するため、それらの中間CAによる偽造証明書はChrome、Edge、Firefox、Safariに届きませんでした。CT非対応クライアントに対して鍵が使われたかどうかはCTログから分からず、インシデントサイトも不明としています。

攻撃はどのように進行しますか？

流れは直線的です。公開証明書から鍵を計算し、対象ドメインの末端証明書を偽造し、接続経路上に位置取りし、CT非対応クライアントにチェーンを検証させます。

攻撃者は何ができますか？

未修正のCT非対応クライアントに対し、攻撃者はTLSで接続する任意のWebサイトやサービスになりすませます。認証情報を収集し、更新フィードとしてマルウェアを配信し、APIトラフィックをリダイレクトできます。すべてクライアントが完全に信頼する証明書を使って行われます。条件は次のとおりです。

• 被害者のトラフィックを傍受または応答できるネットワーク上の位置。被害者には接続以外の操作は不要です。
• 影響対象のルートまたはクロス署名を信頼し、CTを強制せず、ブロックを受信していないクライアント。この組み合わせは現行ブラウザーを除外し、curlベースのツール、独自バンドルを持つランタイムやアプリケーション、修正版より前にビルドされたElectronアプリ、IoTデバイスを含みます。
• それ以外は不要です。鍵は盗まれたのではありません。盗む必要がなく、実質的に証明書自体の中に公開されていたからです。

2つのコード署名中間CAは、それらを信頼するプラットフォーム上の署名済みコードへ理論上の影響範囲を広げます。ただしChromeのTLS検証器はコード署名に制限された中間CAを通る経路を構築せず、コード署名の悪用も報告されていません。偽造TLS証明書がブラウザーへ届かなかったことを確認するCertificate TransparencyはTLS証明書だけを対象とするため、署名済みコードには同等の痕跡を提供しません。

なぜ修正が有効なのですか？

修正は偽造チェーンが通り得るすべての経路を閉じることで機能します。鍵拒否リストは弱い鍵自体を拒否し、バンドルからの削除はルートを断ち、配信された失効情報はブラウザーで中間CAをブロックします。各機構の保護範囲は異なります。

• 最も強力な鍵拒否リスト： Goのcrypto/x509、Node.js、Pythonのsslモジュールは、Sectigoのクロス署名コピーも含め、8つの鍵のいずれかを持つ証明書を拒否します。PythonはSSLContextポリシーにかかわらず各証明書のSubjectPublicKeyInfoのSHA-256ハッシュを照合し、Goの拒否リストには無効化スイッチがありません。
• 最も広範なバンドル削除： certifi、webpki-roots、Debian、Ubuntu、Fedora、RHELなどのディストリビューションパッケージはemSign ECC Root CA - G3を完全に削除し、正当か偽造かにかかわらずルート配下のすべての証明書を遮断します。
• 最も速い失効情報配信： CRLSets、OneCRL、Microsoftの信頼リスト更新は、ソフトウェア更新なしでブラウザーの中間CAをブロックします。

限界も重要です。拒否リストはソフトウェアを再ビルドまたは更新して初めて役立ち、Goバイナリには再コンパイルが必要です。

バンドル削除はルート配下の正当な証明書も遮断し、Mozilla、Canonical、Red Hatはいずれも警告しています。Chromeが10月27日にルート自体を削除したとき、約30,800の有効な証明書が壊れるのもまさにこのためです。

失効ベースの保護は、実際に失効データを取り込むクライアントだけを対象とし、影響を受けるブラウザー以外のクライアントは通常これを行いません。この隙間があるからこそGo、Node.js、Pythonの拒否リスト方式が存在します。Goの課題でFilippo Valsordaは次のように述べています。

「Linuxのルートストアは管理が一貫しておらず、失効情報がアプリケーションまで届かないため、コード内で鍵を拒否します。」

侵害されたかどうかを確認するには？

CT非対応クライアントに対する過去の鍵の悪用を検出する方法は公開されていません。インシデントサイトは、10月17日より前に欠陥のある生成が悪用されたか不明としています。確認できるのは次の点です。

• クライアント側では、コンテナー内やビルドマシンも含め、重要なすべての環境で「影響を受けますか？」節の4つの確認用ホストに接続します。サイトはOpenSSLによるオフライン検証用に、各提供チェーンをPEM形式でまとめたchains.zipと、確認用ホストのユーザーエージェント別成功統計も公開しています。
• サーバー側では、任意のCTログ監視ツールを使い、emSign ECC Root CA - G3またはemSign Root TLS CA - G3につながる証明書を棚卸しします。見つかったものは監視するだけでなく10月27日までに置換しなければなりません。
• 証明書管理側では、ACME構成がACME Renewal Information（RFC 9773）に対応するか確認します。対応しないクライアントは更新期間外に証明書を置換しないため、11月に失効する証明書でも10月27日に壊れることになります。

タイムライン

• 2025-04-30：eMudhraの鍵生成セレモニーで8つの中間CAを作成し、強い鍵の組と並んで弱い鍵の組を生成。
• 2025：eMudhraが同じ中間CAのうち6つについて無効なCRLを公開。後に「欠陥のある鍵で再署名」したと認める。
• 2026-10-17：Wayneが署名付きの証明とともに、復元可能な鍵をルートプログラムへ報告。Chromeは19:45 UTCまでにCRLSetブロックを提供し、Mozillaは22:59 UTCまでにOneCRLを配信。
• 2026-10-19：下流の信頼ストアへ通知。Androidは22:00 UTC頃にGoogle Play services経由でブロックを受信。アドバイザリによればAppleがAppleデバイスで12の中間証明書をブロック開始。eMudhraはMozillaに、2025年のCRLは欠陥のある鍵で再署名したと説明。
• 2026-10-20：MozillaとGoogleが公開。Goが1.27.3と1.26.10をリリース。certifiが2026.10.19をリリース。Firefox 158.0.1とESRがブロックを同梱。Microsoftプラットフォームのブロックが到達。MozillaがNSSからルートを削除。
• 2026-10-21：eMudhraがBSE向けプレスリリースでセレモニーの欠陥を公開。CERT-InがCIAD-2026-0050、Red HatがRHSB-2026-012を公開。Node.jsがブロックリストを提供。Azulが8つの中間CAをブロックする定例外Zulu・Zingビルドを提供。ムンバイでeMudhra株が20パーセント下落。
• 2026-10-22：eMudhra取締役会が世界規模のSSL/TLS事業（売上の約1パーセント）からの撤退を決定。Chromeの12の質問への回答は公開されていない。
• 2026-10-23：アドバイザリによればAppleがemSign ECC Root CA - G3のブロックも開始。
• 2026-10-24：Pythonがsslモジュールの拒否リストをCVE-2026-115557として発表し、3.11～3.15の保守ブランチにバックポート。
• 2026-10-25：Pythonが拒否リストを初めて含む3.15.2、3.14.10、3.13.18、3.12.16、3.11.18をリリース。certifiの現行版が2026.10.23になる。
• 2026-10-27：Chrome Root Storeバージョン43がemSign ECC Root CA - G3を削除し、太平洋時間10月27日朝にデバイスへ届く見込み。Appleのコマンドラインツールを対象とするmacOS更新は10月27日朝時点で未提供で、セキュリティリリース索引にもこのインシデントの項目がないため、組み込みcurl、git、Pythonには以下の/etc/ssl/cert.pemの手動処理が引き続き修正策となる。

よくある質問

今ブラウザーを使っても安全ですか？

はい。Chrome、Edge、Firefox、SafariはCertificate Transparencyを強制しており、6つのTLS中間CAからの証明書は一度もCTログに記録されていません。そのため失効ブロックが届く前も、それらの中間CAの偽造証明書はブラウザーに届きませんでした。10月17日以降のブロックは、ブラウザーがCT確認なしで受け入れ得るものも遮断します。

macOSを更新しました。なぜcurlはまだ脆弱ですか？

Appleは証明書構成の自動更新を通じ、10月19日に12の中間証明書（各TLS中間CAのeMudhraルート配下版とSectigoクロス署名版）、10月23日にルートをブロックしました。これらはSafari、Mail、Appleのネットワーク・セキュリティフレームワークを使うアプリを保護します。

組み込みのcurl、git、Pythonは失効を確認せず/etc/ssl/cert.pemで検証します。Appleアドバイザリ149555は、その修正が「今後のソフトウェア更新で利用可能になる」としています。それまでは手動またはインシデントサイトのスクリプトでファイルからルートを削除してください。macOS更新でファイルが戻る可能性があります。

Webサイトは本当に10月27日に壊れますか？

証明書がemSign ECC Root CA - G3につながる場合だけです。10月21日時点で約30,800の未失効証明書が該当しました。それらについては、はい。Root Storeバージョン43がChromeユーザーへ届くと、チェーンの検証は成功しなくなります。Googleは運営者に、削除を待たず証明書を直ちに置換し、ACMEクライアントはARI対応なしでは早期更新しないことを忘れないよう案内しています。

eMudhraはハッキングされたのですか？

システム侵入も鍵の窃取もなく、そこがこのインシデントの特異な点です。鍵の生成方法が不適切でした。不適切に生成された鍵は実質的に公開されたものであり、証明書を持つ誰でも侵入なしで計算できます。eMudhraによれば8つの中間CAのうち7つは本番で一度も使われず、使用された1つを含め、8つのどれもエンドエンティティ証明書を発行していません。

Sectigoのルートも削除する必要がありますか？

ほかの方法で修正できないクライアントに限ります。8つの中間CAのうち6つはSectigoのAAA Certificate Servicesルート配下のクロス署名版もあるため、emSign ECC Root CA - G3だけを削除すると、それらの経路が残ります。しかしAAAを削除すると配下の正当な証明書もすべて遮断されます。このため両方を削除するディストリビューション更新は障害についても警告し、鍵拒否リストの修正が存在するならそちらが優れた対応となります。

10月20日にインストールしたGoの緊急更新と同じですか？

はい。Goはその日、CA名を明かさずに1.27.3と1.26.10をリリースし、URGENT経路でcrypto/x509の8つの鍵ハッシュをブロックしました。8つのハッシュはこれらの8証明書に一致します。Goセキュリティチームは、欠陥の悪用が非常に容易で詳細が当日中に公開されると見込んだため、リリースノートを曖昧にしたと説明しています。

10月27日に機能しなくなる証明書を見つける

Ostorlab Attack Surface Discoveryで、所有するインターネット公開ドメインとホストを棚卸ししてください。その後、各ホストが提供する証明書チェーンにemSign ECC Root CA - G3がないか確認し、Chromeが10月27日にルートを削除する前に一致するものを置換します。

参考資料

• 証明、確認用ホスト、オフラインチェーンバンドル、修正状況一覧を含むインシデントサイト。2026年10月20日から保守：https://emudhra.we-have-a-problem.com/ （2026年10月27日確認）
• 侵害されたeMudhra中間CAに関するAppleアドバイザリ149555。10月19日から中間CA、10月23日からルートをブロック、/etc/ssl/cert.pem修正は今後の更新、手動削除手順を記載。2026年10月27日朝に該当項目を確認したAppleセキュリティリリース索引：https://support.apple.com/en-us/149555 および https://support.apple.com/en-us/100100 （2026年10月27日確認）
• eMudhra中間CA侵害に関するAzulの声明、2026年10月22日。8つの中間CAをブロックする10月21日の定例外Zulu・Zingビルドを記載：https://www.azul.com/newsroom/azul-statement-on-the-emudhra-intermediate-ca-certificates-compromise/ （2026年10月26日確認）
• 侵害されたeMudhra中間CA証明書からChromeとAndroidユーザーを保護するGoogleの記事、2026年10月20日：https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/ （2026年10月25日確認）
• Firefoxユーザー保護に関するMozillaの記事、2026年10月20日：https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ （2026年10月25日確認）
• 報道で引用されたChrome Root ProgramとMozillaポリシーリストのスレッド：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ （2026年10月25日確認）
• 2025年4月30日のセレモニーの欠陥に関してBSE証券取引所へ提出されたeMudhraプレスリリース：https://www.bseindia.com/xml-data/corpfiling/AttachLive/6be0c423-b335-494b-86f3-54c561c3a5f9.pdf （2026年10月25日確認）
• eMudhraの証明書セキュリティインシデント声明：https://emudhra.com/en/post/certificate-security-incident （2026年10月25日確認）
• Scott Helmeによる独立した鍵復元。8つすべてを1秒未満で復元し、1つは数字の4：https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ （2026年10月25日確認）
• 8つの侵害されたCA鍵とエコシステムの緊急修正についてのThe Hacker News記事、2026年10月20日、10月21日更新：https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html （2026年10月25日確認）
• eMudhraの世界規模SSL/TLS事業撤退、約30,800の未失効証明書、InCommonへの集中、Chromeの10月27日削除についてのThe Hacker News記事、2026年10月22日：https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html （2026年10月25日確認）
• 8つの鍵をブロックするGoの緊急リリース、CVE-2026-111943：https://groups.google.com/g/golang-announce/c/66pojueaQek および https://cveawg.mitre.org/api/cve/CVE-2026-111943 （2026年10月25日確認）
• Pythonのsslモジュール拒否リスト発表、CVE-2026-115557、2026年10月24日：https://www.openwall.com/lists/oss-security/2026/10/24/5 および https://cveawg.mitre.org/api/cve/CVE-2026-115557 （2026年10月25日確認）
• Mozillaのスコアなし、CISAの5.4 Medium補足評価を含むFirefox CVE-2026-113470レコード：https://cveawg.mitre.org/api/cve/CVE-2026-113470 （2026年10月27日確認）
• 拒否リストが10月25日に3.15.2、3.14.10、3.13.18、3.12.16で初提供されたことを示すCPythonリリース変更履歴と、同日タグ付けのv3.11.18がバックポートを含むことを確認する比較表示：https://docs.python.org/3.15/whatsnew/changelog.html および https://github.com/python/cpython/compare/af52b41afa4330fb38583db553631baa2f122f90...v3.11.18 （2026年10月26日確認）
• eMudhraルートを削除するOracleの定例外Java警告、CVE-2026-114820：https://www.oracle.com/security-alerts/alert-cve-2026-114820.html （2026年10月25日確認）
• emSignルートを削除するcertifiアドバイザリGHSA-6q48-6c7w-9gw2：https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2 （2026年10月25日確認）
• emSignルートを削除するuvアドバイザリGHSA-hq85-5cpj-mr62：https://github.com/astral-sh/uv/security/advisories/GHSA-hq85-5cpj-mr62 （2026年10月25日確認）
• RHEL信頼ストアの回避策を含むRed Hatセキュリティ速報RHSB-2026-012：https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 （2026年10月25日確認）
• CERT-InアドバイザリCIAD-2026-0050、2026年10月21日：https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050 （2026年10月25日確認）
• Cloudflareの修正済みWARP、1.1.1.1クライアント、cloudflared 2026.10.2：https://blog.cloudflare.com/emudhra-certificate-compromise （2026年10月25日確認）
• mongosh 2.14.0リリース、2026年10月23日。鍵ブロックリスト付きNode 24.22.1を同梱。それ以前はホストNodeランタイムの信頼ストアで検証：https://github.com/mongodb-js/mongosh/releases/tag/v2.14.0 （2026年10月27日確認）