セキュリティ研究者を名乗る「Nightmare Eclipse」が、複数のWindowsゼロデイ脆弱性の実証コード（PoC）を、ベンダーとの協調的脆弱性開示（CVD）を経ずに公開しました。ベンダーの修正パッチがまだ無い状態でPoCが出回る「空白期間」が生じており、Microsoftはこれを強く非難しています。情シスにとっての要点は単純です。特定のCVE番号を追うより先に、「パッチが無い脆弱性が公表されたとき、自組織は何をするのか」という段取りを持っているかどうかが問われています。さらに研究者は2026年7月14日に追加の公開を予告しており、状況は流動的です。
この記事でわかること
- 何が「無断公開」で、なぜ通常のゼロデイより厄介なのか
- 今回の件で「確認できていること」と「まだ確認できていないこと」の切り分け
- パッチが出るまでの空白期間に情シスが打てる現実的な一手
何が起きたのか
複数の報道によると、Nightmare Eclipseを名乗る人物・グループが2026年5月下旬（23〜26日ごろ）、GitHubやGitLabといったソースコード共有サービス上に、Windows関連の複数のゼロデイ脆弱性のPoCを掲載しました。これらのアカウントやリポジトリはその後、停止・削除されています。公開された脆弱性には「RedSun」「UnDefend」「BlueHammer」「YellowKey」「GreenPlasma」「MiniPlasma」といったコードネームが付けられ、Windows DefenderやBitLockerなど、OSの保護機能そのものに関わる領域が含まれるとされています。
Microsoftはこれを、CVD（協調的脆弱性開示）の手順を踏まない一方的な公開だとして非難し、修正パッチの開発を進めるとともに、法執行機関との連携も検討していると報じられています。MSRC（Microsoft Security Response Center）は通常、報告を受けた脆弱性を月例のセキュリティ更新プログラムで修正しますが、今回は「先に世に出てしまった」順序が問題を大きくしています。
「無断公開」はなぜ通常のゼロデイより厄介なのか
防御側の準備期間がまるごと消えるためです。本来のゼロデイ対応でも情シスは後手に回りがちですが、CVDでは「ベンダーが修正を用意し、パッチと注意喚起を同時に出す」ことで、利用者が更新を適用できる導線が最初から用意されます。ところが今回のように動くPoCが先に公開されると、攻撃者はパッチが出る前に手法をそのまま流用できます。エンタープライズ環境ほど検証や展開に時間がかかるため、その間の露出（さらされている状態）が長引くという構造的な不利があります。ゼロデイ攻撃そのものの仕組みはゼロデイ攻撃とは？仕組み・なぜ防げないかと情シスの備えで解説していますが、今回はそこに「PoCが公開済み」という条件が上乗せされている、と捉えると分かりやすいはずです。
確認できていること／まだ確認できていないこと
この種の話は伝聞で膨らみやすいため、事実と未確認情報を分けて扱います。過度に不安を煽るのも、逆に軽視するのも避けるべきです。
| 項目 | 現時点の扱い |
|---|---|
| PoCがCVDを経ずに公開された事実 | 複数の報道で一致。確度は高い |
| コードネーム（RedSun 等）と対象領域（Defender / BitLocker 等） | 報道ベース。名称は共通するが、細部は各報道に依存 |
| 個々の脆弱性のCVE番号 | 一部は採番済みだが、多くは未確認。番号を鵜呑みにしない |
| 「すでに悪用が確認されている」との指摘 | 一部にそうした報道はあるが範囲は不明確。断定は避ける |
| 7月14日の追加公開予告 | 研究者側の予告。実施されるか・内容は未確定 |
なお、この一連のうちBitLocker回避に関わるものについては、JPCERT/CCが公表した CVE-2026-45585（Windows回復環境WinREを経由した保護回避、物理アクセスが前提）が実在し、別途整理しています。詳細はWinREのBitLocker回避 CVE-2026-45585を参照してください。逆に言えば、コードネームだけが独り歩きしている脆弱性については、CVE番号や影響条件が確定するまで自組織への影響を過大にも過小にも見積もらないことが大切です。
現場目線の課題
正直なところ、こうした報を受けて情シスが最初に困るのは「で、うちの何台が対象なの？」の一点に尽きます。コードネームと断片的な報道だけでは、資産管理台帳と突き合わせようにも突き合わせられません。パッチが無い以上「更新して終わり」にもできず、経営層や現場からは「危ないの？大丈夫なの？」と二択で急かされる——限られた人員で、確定していない情報に対して説明責任だけが先に発生する、というのが実感に近いところです。だからこそ、個別の脆弱性を追いかける前に、後述する「空白期間の型（動き方の手順）」を持っておくことが効いてきます。
情シスはどうすべきか（空白期間の暫定対応）
パッチが出るまでの間にできることは限られますが、ゼロではありません。優先順位の高い順に整理します。
- 資産の把握を先に固める：対象になりうるOS・機能（例：Windows Defender、BitLocker利用端末）の台数と配置を、確定情報が来た瞬間に照合できる状態にしておく。ここが遅いと、いくら情報が出ても動けません。
- ベンダーの一次情報を待って正しく更新する：コードネームや第三者記事ではなく、MicrosoftのセキュリティアドバイザリとJPCERT/CC等の注意喚起を確認源にする。JPCERT/CCの注意喚起は日本語で追いやすく有用です。
- 検知・監視を厚くする：パッチが無い局面では「侵入を前提に、異常を早く気づく」ことが要になります。EDRのアラート運用を見直し、公開されたPoCに関連する挙動が検知対象に含まれるか確認します（EDRの位置づけはEDRとは？仕組みとEPP・XDRの違いを解説を参照）。
- 緩和策と優先度付け：ベンダーが暫定回避策（構成変更・機能の一時制限など）を示したら、影響とのバランスを見て適用を判断します。すべてを一律に急ぐのではなく、「悪用が現実的なもの」から優先します。
- 公的指針を土台にする：自前で長大なチェックリストを作るより、体制づくりの土台としてIPAの中小企業の情報セキュリティ対策ガイドラインや、利用者向け啓発の対策のしおりを参照するのが近道です。地道な社内周知（不審なリポジトリ・実行ファイルを安易に試さない等）も、こうした局面では効いてきます。
中長期の視点：協調的脆弱性開示（CVD）という仕組み
今回の件は、CVD（Coordinated Vulnerability Disclosure）という「見つけた人・直す人・使う人」の順序を守る仕組みが、なぜ利用者の安全に直結するのかを逆側から教えてくれます。日本ではIPAとJPCERT/CCが運用する「情報セキュリティ早期警戒パートナーシップ」が、届出から修正・公表までを調整する役割を担っています。情シスの立場では、脆弱性を自ら発見した場合の届け先を知っておくこと、そして「公開が先行してしまった脆弱性」を平時から想定した運用手順を持っておくことが、次に同じことが起きたときの初動を速くします。
まとめ
- Nightmare EclipseによるWindowsゼロデイのPoC無断公開で、パッチ提供前にPoCが出回る「空白期間」が生じている。7月14日に追加公開の予告もあり流動的。
- コードネームや悪用状況は報道ベースで未確定な部分が多い。CVE番号が確定しているCVE-2026-45585などを軸に、事実と伝聞を切り分けて扱う。
- 情シスの打ち手は「資産把握を先に固める → 一次情報で更新 → 検知・監視を厚く → 緩和策を優先度順に → 公的指針を土台に」。個別CVEを追う前に、この空白期間の型を持つことが効く。
