今天刷到这个消息的时候，我整个人愣住了。一个代号为"YellowKey"的漏洞，居然能让攻击者用一根U盘绕过Windows 11的BitLocker全盘加密——这相当于你花大价钱买的保险柜，被人用回形针捅开了。
事情是这样的。月初，一位GitHub昵称为Nightmare-Eclipse的安全研究员公开披露了这个漏洞。按照他的说法，这是"我迄今为止最疯狂的发现之一"。微软本周终于承认了问题的存在，给它编了个CVE编号：CVE-2026-45585。但截至发稿，补丁还没影。
让我试着把这个漏洞的逻辑讲清楚，因为这里面有些东西挺反直觉的。
BitLocker是什么？简单说就是Windows自带的磁盘加密工具，号称能保护你的数据即使设备被盗也不会泄露。企业用户、对隐私敏感的个人用户，很多人靠它求个心安。而Windows Recovery Environment（WinRE）是什么？就是那个系统崩溃时跳出来救场的恢复环境，蓝屏之后"正在准备自动修复"的界面。
YellowKey的诡异之处在于，它利用的恰恰是WinRE的"正常行为"。网络安全公司Eclypsium的分析说得很直白：攻击者可以通过WinRE"获得一个完全解锁的命令行shell，而操作系统仍然认为这些驱动器处于加密状态"。翻译成人话——加密锁还在，但门已经开了。
具体攻击场景听起来像电影桥段：偷一台Windows 11笔记本，插个U盘，完事。Eclypsium的原话是"一台被盗的Windows 11笔记本和一个U盘"就是全部所需。U盘里的文件系统格式也不挑，NTFS、FAT32、exFAT都能用，攻击者想怎么布置 payload 都行。
这里有个让人困惑的细节。Nightmare-Eclipse测试后认为，这个漏洞似乎只在Windows 11上存在。Eclypsium的解释是，负责这个功能的WinRE组件在Windows 10的代码库里"行为不同"。但Nightmare-Eclipse的进一步观察更耐人寻味——他发现触发漏洞的那个组件，在普通Windows安装里也有，同名同姓，但偏偏少了那个能绕过BitLocker的功能。
"这个负责漏洞的组件除了WinRE镜像里，其他地方根本找不到（连互联网上都没有）。"Nightmare-Eclipse写道，"更让人起疑的是，完全相同的组件也以完全相同的名称存在于普通Windows安装中，但偏偏没有触发BitLocker绕过问题的那些功能。"
他把这个现象称为"更像是后门"。微软没有回应这个猜测，官方定性是"安全功能绕过漏洞"。
微软的回应也挺有意思。他们批评了Nightmare-Eclipse公开分享概念验证代码的做法，说这违反了"协调漏洞披露最佳实践"。但另一方面，微软自己也只提供了"缓解指导"，没给补丁。缓解措施包括什么？主要是物理安全——别让坏人碰到你的电脑。
这个要求物理接触的前提，确实是漏洞影响范围的一个天然限制。远程攻击者没法隔着网线用这个漏洞。但对于设备可能失窃的场景——企业笔记本、出差用的工作机、放在办公室的台式机——这个"缓解"听起来有点黑色幽默。
说实话，Windows 11今年的安全记录确实不太好看。上个月才有研究员警告，那个被微软大力推广的AI功能Recall存在被恶意利用的风险。再往前，连记事本这种"从良多年"的基础应用都爆出了远程代码执行漏洞。现在BitLocker这种核心安全功能也被捅穿，很难不让人想问：Windows 11的安全架构到底怎么了？
Recall的事情值得多说两句。这个功能本意是用AI帮你"记住"在电脑上做过的一切，方便搜索。但安全研究发现，它产生的数据可能被恶意软件读取，相当于给攻击者开了个详细的活动日志。微软后来被迫调整，改成默认关闭、需要用户主动启用。但风向已经很明显——AI功能被急着推上线，安全似乎成了事后补丁。
回到YellowKey。对于普通用户，现在能做什么？微软的缓解建议包括：启用BitLocker的预启动身份验证（需要输入PIN或插入USB密钥才能启动）、确保WinRE环境本身也有密码保护、物理上保护好设备。但这些措施要么增加使用门槛，要么对已经配置好的系统改动麻烦，要么……就是那句"别让人偷你电脑"的车轱辘话。
企业IT管理员可能更头疼。BitLocker大规模部署的环境里，这个漏洞意味着"设备丢失=数据可能泄露"，而不是原来以为的"设备丢失但至少数据安全"。合规部门、风险评估、保险条款，可能都要重新过一遍。
Nightmare-Eclipse的发现方式也很有意思。他没有说自己是通过什么路径找到这个漏洞的，但从描述看，似乎是对WinRE组件进行深度逆向分析时注意到了异常。那个"只存在于WinRE镜像中"的组件，那个普通Windows安装里同名但功能不同的组件——这种差异本身就是值得深挖的线索。安全研究有时候就是这样，不是去找明显的漏洞，而是去问"为什么这里和那里不一样"。
微软最终会怎么修这个漏洞？可能的方式包括：修改WinRE的行为，让它无法被滥用进入解锁状态；或者给BitLocker增加额外的验证步骤，确保即使WinRE被操控也无法直接访问加密数据。但无论哪种，都需要更新WinRE镜像，而WinRE的更新 historically 比常规系统更新更麻烦，有时候需要手动触发或特殊部署流程。
这个漏洞也抛出一个更深层的问题：恢复环境和安全机制之间的边界应该怎么划？WinRE的设计初衷是"当系统无法正常启动时，提供一个修复入口"。但这个入口的权限有多大？它应不应该能接触到加密数据？理想情况下，恢复操作应该在加密框架内进行，而不是绕过去。但工程上的权衡往往是——为了"能修好"，不得不给恢复环境开一些后门。YellowKey可能就是这种权衡的意外后果。
对于还在用Windows 10的用户，这倒是成了一个意外的"优势"。漏洞似乎不影响Windows 10，虽然微软正在推动用户升级，但安全敏感的场景下，多观望一阵子或许不是坏事。当然，Windows 10的支持周期也在倒计时，这不是长久之计。
最后想说的是，这个漏洞的发现和披露过程本身，也反映了安全研究社区和厂商之间的张力。微软批评公开披露，但协调披露的前提是厂商能及时响应。CVE-2026-45585已经存在一段时间了，补丁还没出，研究员选择公开细节，某种程度上也是在用公众压力推动修复。这种博弈没有标准答案，但站在用户角度，知道风险的存在总比蒙在鼓里强。
如果你的Windows 11设备存储着敏感数据，又存在物理失窃风险，现在可能需要额外警惕。BitLocker不是银弹，这个我们知道了。问题是，下一个"最疯狂的发现"会是什么？
热门跟贴