| 4 月 7 日 | BlueHammer 附带完整概念验证代码(PoC)公开发布 。 |
| 约 4 月 10 日 | Barracuda 和 Huntress 发现,已有攻击者利用据称位于俄罗斯的基础设施对该漏洞进行活跃利用 。 |
| 4 月 14 日 | 微软在当月的“补丁星期二”中修复了 BlueHammer,对应漏洞编号为 CVE-2026-33825(CVSS 评分 7.8) 。 |
| 4 月 16 日 | 研究员公布 RedSun(利用 Defender 云文件回滚机制的提权漏洞)和 UnDefend(可禁用 Defender 签名更新功能)。Huntress 确认,三个 Defender 漏洞均已在野外遭到活跃攻击 。 |
| 约 4 月 17 日 | CISA 将 CVE-2026-41091(RedSun)和 CVE-2026-45498(UnDefend)加入其已知被利用漏洞(KEV)目录,强制要求联邦机构在 6 月 3 日前完成修复 。 |
| 5 月 12 日 | YellowKey(通过 WinRE 绕过 BitLocker 加密)和 GreenPlasma(利用 CTFMON 实现 SYSTEM 权限提升)在 5 月补丁星期二的第二天被公开 。 |
| 5 月 17 日 | 研究员发布 MiniPlasma——一个能在已打全所有补丁的 Windows 11 系统上获取 SYSTEM 权限的漏洞 。 |
| 5 月 19 日 | ThreatLocker 证实 MiniPlasma 确实能在完全更新的系统上有效运行 。 |
| 5 月 21 日 | 微软为 RedSun 和 UnDefend 发布紧急带外补丁 。 |
| 约 5 月 23 日 | GitHub 封禁 Nightmare-Eclipse 的账户 。 |
| 约 5 月 26-27 日 | GitLab 跟进封禁其关联账户 。 |
| 5 月 27 日 | 微软发布题为“共同的责任”的博客文章,谴责这种公开披露行为,并暗示其数字犯罪部门(DCU)可能会采取法律行动 。 |
| 7 月 14 日(威胁发布日) | 该研究员警告将在这一天(下一个补丁星期二)再次进行漏洞大规模公开 。 |
截至 2026 年 5 月底,六个漏洞中已有三个得到修复。仍有三个未修复,其中 MiniPlasma 最令安全团队头疼,因为它直接在最新系统上有效。
| 漏洞名称 | 类型/目标 | CVE 编号 | CVSS 评分 | 补丁状态 |
|---|---|---|---|---|
| BlueHammer | 在 Microsoft Defender 中实现本地提权至 SYSTEM | CVE-2026-33825 | 7.8 | 已修复 — 4 月 14 日补丁星期二 |
| RedSun | Microsoft Defender 本地提权 | CVE-2026-41091 | 7.8 | 已修复 — 5 月 21 日带外补丁 |
| UnDefend | 禁用 Defender 签名更新 | CVE-2026-45498 | 4.0 | 已修复 — 5 月 21 日带外补丁 |
| YellowKey | 通过 WinRE 绕过 BitLocker | CVE-2026-45585 | 6.8 | 未修复 — 仅提供了缓解指南 |
| GreenPlasma | CTFMON 实现 SYSTEM 权限提升 | 未分配 | 未分配 | 未修复 |
| MiniPlasma | 在已打全补丁的 Win11 上提权至 SYSTEM | 未分配 | 未分配 | 未修复 — ThreatLocker 已证实其有效性 |
MiniPlasma 最为危险,因为它允许一个标准用户权限的程序,在已安装所有 2026 年 5 月更新的系统上,直接获取 SYSTEM 级别的最高权限 。这个漏洞利用了与 BlueHammer 相同的 cldflt.sys 云文件驱动,通过重新触发一个 2020 年的旧漏洞(CVE-2020-17103)来实现攻击。研究员声称,微软当年宣称已修复该问题,但实际上并未根除 。
该研究员明确表示,这一系列披露就是为了报复 MSRC 对他的不公对待。公开声明和多篇报导指出,他此前私下向微软提交的漏洞报告遭到了冷遇、处理缓慢,或对方提出了在他看来非常过分的要求——据称,MSRC 甚至要求他提供一段漏洞利用的视频演示 。一句据称是他所说的、被广泛引用的指控是:“微软曾威胁要‘毁掉我的生活’,而他们确实也这么做了。”
后续漏洞的发布时间也极具挑衅性。YellowKey 和 GreenPlasma 被刻意放在 5 月补丁星期二的第二天公开,而 MiniPlasma 则是在五天后接踵而至 。这种策略的目的性非常明确:就是为了最大化曝光和施压。
5 月 27 日,微软发布了一篇题为 “共同的责任:通过协调漏洞披露保护客户” 的博客文章 。这篇文章:
微软强硬的措辞无疑升级了双方的对立,但却未能解决最核心的问题:仍有三个零日漏洞没有补丁。与此同时,代码托管平台采取了行动。GitHub 约在 5 月 23 日封禁了该研究员的账号,几天后,GitLab 也采取了同样的措施 。
到 4 月中旬,首批三个针对 Defender 的漏洞已全部遭到野外利用。Huntress 和 Barracuda 发现,攻击者直接从公开的 GitHub 仓库中提取 PoC 代码,并使用地理位置位于俄罗斯的基础设施发起攻击 。
CISA 对此反应迅速。BlueHammer 于 4 月 22 日被加入 KEV 目录,并要求联邦机构在 5 月 6 日之前完成修复 。随后 RedSun 和 UnDefend 也被添加其中,修复期限是 6 月 3 日 。这些举措反映出一种深层的忧虑:当安全软件本身成为攻击的载体时,传统的防御模型就会从根基上被瓦解。
网络安全界对此事给出了截然相反的评价。
对研究员的批评主要来自 Barracuda、ThreatLocker 及 LevelBlue 等公司。他们认为,这种公开投掷“武器化”漏洞代码的做法是危险且适得其反的,直接将企业用户暴露在了无补丁可用的即时风险之中 。
对微软的批评同样尖锐。许多业内人士指出,如果 MSRC 以更尊重、更积极的态度来与漏洞发现者沟通,这整场风波本可以避免。这一连串的披露事件,重新揭开了微软安全响应流程上的旧伤疤:漏洞分拣速度慢、沟通不透明、对那些不适合企业赏金模式的独立研究员采取对抗姿态 。
评论家还指出了一个自相矛盾的戏剧性场面:微软在三个高危漏洞仍无补丁可用的关键时刻,威胁要对披露者采取法律行动。这种行为被批评为“做做样子”和“轻重不分” 。
研究员在被平台封杀后陷入了沉寂,但并未彻底消失。失去 GitHub 和 GitLab 的账户后,他转移到了一个个人博客上,并明确威胁将在 7 月 14 日——也就是下一个微软补丁星期二——进行更大规模的漏洞“轰炸” 。这个威胁是否真实还有待观察,但其行动模式已然确立。
对于安全团队而言,眼下的重中之重已非常清晰:立即应用微软为 Defender 漏洞发布的带外补丁;实施针对 YellowKey 的缓解措施(删除 WinRE 镜像中 BootExecute 注册表项里的 autofstx.exe,并为 BitLocker 启用“TPM+PIN”验证);同时应将 MiniPlasma 视为一个无可官方修复方案的已知高危威胁。此外,还要警惕针对未来补丁星期二再被“搭车”放出更多 PoC 的可能,并为已成为攻击者“靶场”的 Defender 组件提前准备好应急性的安全管控。
噩梦-Eclipse 事件远不止是六个技术漏洞那么简单。它是一次对平台供应商与其赖以生存的外部安全研究员之间关系的极限压力测试。事实表明,当这个合作关系破裂时,其后果就是公之于众的、可被利用的,并且是异常严重的。