【更新 2026-07-13】本記事を見直し、修正しました。主な修正点：(1) BitLocker回避 CVE-2026-45585 の公表元を「JPCERT/CC」から「Microsoft（MSRC）」に訂正（NVDのCNA表記に基づく）、(2) 悪用状況の続報として BlueHammer（CVE-2026-33825）がCISAのKEVカタログに登録され、ランサムウェアによる悪用もCISAが警告している点を反映。あわせて、無断公開の時期と法的措置に関する記述に「要確認」の注記を追加しました。
【更新 2026-08-12】本記事を見直し、修正しました。主な修正点：(1) 予告されていた7月14日の追加公開が実際に行われ（「LegacyHive」）、2026年8月11日の月例更新で CVE-2026-62832 として修正された経緯を反映、(2) 前回「要確認」とした2点（無断公開の時期、Microsoftの法的措置の方針）について一次情報・複数報道で裏が取れたため、注記を確定情報に置き換え、(3) RedSun（CVE-2026-41091）・UnDefend（CVE-2026-45498）もCISA KEV登録済み（2026-05-20）である点と、主要な脆弱性のCVE番号・修正状況を更新。
セキュリティ研究者を名乗る「Nightmare Eclipse」が、複数のWindowsゼロデイ脆弱性の実証コード（PoC）を、ベンダーとの協調的脆弱性開示（CVD）を経ずに公開しました。ベンダーの修正パッチがまだ無い状態でPoCが出回る「空白期間」が生じ、Microsoftはこれを強く非難しました。情シスにとっての要点は単純です。特定のCVE番号を追うより先に、「パッチが無い脆弱性が公表されたとき、自組織は何をするのか」という段取りを持っているかどうかが問われています。なお、研究者が予告していた2026年7月14日の追加公開はその後実際に行われ（Windows User Profile Serviceの権限昇格「LegacyHive」）、約1か月後の2026年8月11日の月例更新で CVE-2026-62832 として修正されています。
この記事でわかること
- 何が「無断公開」で、なぜ通常のゼロデイより厄介なのか
- 今回の件で「確認できていること」と「まだ確認できていないこと」の切り分け
- パッチが出るまでの空白期間に情シスが打てる現実的な一手
何が起きたのか
複数の報道によると、Nightmare Eclipseを名乗る人物・グループが2026年4月から6月にかけて断続的に、GitHubやGitLabといったソースコード共有サービス上に、Windows関連の複数のゼロデイ脆弱性のPoCを掲載しました。これらのアカウントやリポジトリはその後、停止・削除されています。公開された脆弱性には「RedSun」「UnDefend」「BlueHammer」「YellowKey」「GreenPlasma」「MiniPlasma」といったコードネームが付けられ、Windows DefenderやBitLockerなど、OSの保護機能そのものに関わる領域が含まれるとされています。
Microsoftはこれを、CVD（協調的脆弱性開示）の手順を踏まない一方的な公開だとして非難し（2026年5月28日のMSRCブログ）、Digital Crimes Unitによる法的対応にも言及しました。ただしこの表明は研究コミュニティの強い反発を招き、Microsoftは2026年6月初めにMSRCの公式Xで「セキュリティ研究を実施・公表する個人に対して法的措置を取る意図はない」と明言し、法的対応は実害を伴う悪意ある活動に限られると位置づけ直しています。MSRC（Microsoft Security Response Center）は通常、報告を受けた脆弱性を月例のセキュリティ更新プログラムで修正しますが、今回は「先に世に出てしまった」順序が問題を大きくしています。
「無断公開」はなぜ通常のゼロデイより厄介なのか
防御側の準備期間がまるごと消えるためです。本来のゼロデイ対応でも情シスは後手に回りがちですが、CVDでは「ベンダーが修正を用意し、パッチと注意喚起を同時に出す」ことで、利用者が更新を適用できる導線が最初から用意されます。ところが今回のように動くPoCが先に公開されると、攻撃者はパッチが出る前に手法をそのまま流用できます。エンタープライズ環境ほど検証や展開に時間がかかるため、その間の露出（さらされている状態）が長引くという構造的な不利があります。ゼロデイ攻撃そのものの仕組みはゼロデイ攻撃とは？仕組み・なぜ防げないかと情シスの備えで解説していますが、今回はそこに「PoCが公開済み」という条件が上乗せされている、と捉えると分かりやすいはずです。
確認できていること／まだ確認できていないこと
この種の話は伝聞で膨らみやすいため、事実と未確認情報を分けて扱います。過度に不安を煽るのも、逆に軽視するのも避けるべきです。
| 項目 | 現時点の扱い |
|---|---|
| PoCがCVDを経ずに公開された事実 | 複数の報道で一致。確度は高い |
| コードネーム（RedSun 等）と対象領域（Defender / BitLocker 等） | 報道ベース。名称は共通するが、細部は各報道に依存 |
| 個々の脆弱性のCVE番号 | 主要なものは採番済み（BlueHammer: CVE-2026-33825／RedSun: CVE-2026-41091／UnDefend: CVE-2026-45498／YellowKey: CVE-2026-45585＝Microsoftのアドバイザリがコードネームを明記）。一方でRoguePlanet・GreatXMLなど未採番のものも残り、コードネームとCVEの対応は報道ベースのものも含む |
| 「すでに悪用が確認されている」との指摘 | BlueHammer（CVE-2026-33825）はCISAのKEVカタログに登録済み（2026-04-22。ランサムウェア悪用フラグは「Known」）。さらにRedSun（CVE-2026-41091）・UnDefend（CVE-2026-45498）も2026-05-20にKEVへ登録され、Microsoft自身も「Exploitation Detected」と評価している。一方でYellowKey（CVE-2026-45585）等はKEV未登録。コードネームごとに一次情報で個別に確認する |
| 7月14日の追加公開予告 | 実施された。7月の月例更新（2026-07-14）直後に「LegacyHive」（Windows User Profile Serviceの権限昇格）のPoCが公開され、2026年8月11日の月例更新でCVE-2026-62832として修正済み |
なお、この一連のうちBitLocker回避に関わるものについては、Microsoft（MSRC）が公表した CVE-2026-45585（Windows回復環境WinREを経由した保護回避、物理アクセスが前提）が実在し、別途整理しています（Microsoftのアドバイザリはこの脆弱性をコードネーム「YellowKey」として明記。当初はWinREのBootExecuteから該当実行ファイルを取り除く緩和策の提示にとどまりましたが、2026年6月9日の改訂で6月の月例更新へのリンクが追加され、修正が提供済みです）。詳細は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日の追加公開も実際に行われ（LegacyHive）、修正は約1か月後の2026年8月11日だった。
- BlueHammer（CVE-2026-33825）・RedSun（CVE-2026-41091）・UnDefend（CVE-2026-45498）はCISA KEV登録済みで、BlueHammerはランサムウェア悪用も確認されている。CVE番号が確定しているもの（CVE-2026-45585＝YellowKey、CVE-2026-62832＝LegacyHive など）を軸に、事実と伝聞を切り分けて扱う。
- 情シスの打ち手は「資産把握を先に固める → 一次情報で更新 → 検知・監視を厚く → 緩和策を優先度順に → 公的指針を土台に」。個別CVEを追う前に、この空白期間の型を持つことが効く。
出典・参考
- Microsoft、立て続けのゼロデイ脆弱性公表を非難。発見者は7月に報復と予告（PC Watch, 2026-05-29）
- Microsoft激怒のゼロデイ脆弱性「無断公開」 パッチを待つのが危険な理由（TechTargetジャパン, 2026-06-17）
- Microsoft Security Response Center（MSRC）
- MSRC セキュリティ更新プログラム ガイド CVE-2026-45585（Windows BitLocker Security Feature Bypass／YellowKey）
- MSRC セキュリティ更新プログラム ガイド CVE-2026-62832（Windows User Profile Service 権限昇格／2026年8月月例更新）
- CISA Known Exploited Vulnerabilities (KEV) Catalog（CVE-2026-33825: 2026-04-22 追加／CVE-2026-41091・CVE-2026-45498: 2026-05-20 追加）
- JPCERT/CC／IPA 中小企業の情報セキュリティ対策ガイドライン
