一个本地权限提升漏洞能让攻击者从普通用户直接跳到SYSTEM，微软的修复方案不是打补丁，而是把整个功能连根拔掉。
这个编号CVE-2026-20817的漏洞藏在Windows错误报告服务（WER）里。GMO Cybersecurity的研究员Denis Faiustov和Ruslan Sayfiev发现，WER服务处理客户端请求时权限校验有缺陷，低权限用户能触发高权限命令执行。微软评估后认为结构风险太高，直接在代码里埋了个开关，永久禁用了整个功能模块。
15年老功能的"临终关怀"
Windows错误报告服务从Windows XP时代就存在，负责收集程序崩溃信息并上报微软。它的设计复杂在需要跨进程通信：普通程序崩溃后，WER要启动一个高权限进程来处理转储文件，这就天然存在权限边界模糊的地带。
这次漏洞的核心在WerSvc.dll的ALPC（高级本地过程调用）消息处理逻辑。攻击者先通过NtAlpcConnectPort API连接到\WindowsErrorReportingServicePort端口，再用NtAlpcSendWaitReceivePort发送精心构造的数据包。消息里的MessageFlags参数和结构填充必须完全匹配，才能触发漏洞分发器。
攻击链的精妙之处在于File Mapping对象的操控。WER内部的ElevatedProcessStart函数会复制句柄，通过MapViewOfFile读取攻击者注入的命令行参数，最终调用CreateElevatedProcessAsUser——这个本该用于启动WerFault.exe的函数，被欺骗着以SYSTEM权限执行了攻击者控制的参数。
安全研究员对比10.0.26100.7309和10.0.26100.7623两个版本的WerSvc.dll时发现，微软没加权限检查，没做输入过滤，而是直接塞了个__private_IsEnabled()函数测试。如果检测到补丁环境，SvcElevatedLaunch功能直接返回0x80004005（E_FAIL）错误码，整个攻击面被物理移除。
这种"功能截肢"式的修复在微软安全史上极其罕见。
从崩溃报告到SYSTEM权限的跳跃
漏洞利用并非一键完成。WerFault.exe虽然是SYSTEM权限启动，但它本身是个合法程序，攻击者需要结合特定命令行参数和Windows内部技巧才能实现任意代码执行。
利用过程中，WER服务会伪造父进程ID，让新启动的高权限进程看起来像是某个系统组件的子进程。这种"身份伪装"能绕过部分行为监控，但攻击者仍需解决一个关键问题：如何让WerFault.exe执行非预期的操作。
研究员的PoC利用了WerFault.exe的自定义转储路径参数。通过控制文件映射对象里的命令行，攻击者能让SYSTEM权限的进程写入特定目录——而某些目录的权限配置允许后续提权链的展开。整个过程需要精确控制内存布局，但漏洞本身的稳定性很高，因为ALPC消息的触发条件是确定性的。
微软在3月安全更新中推送了这个"修复"。对于企业环境来说，这意味着依赖WER自动收集崩溃日志的某些工作流可能失效，但安全团队普遍认可这种取舍——一个能被稳定利用的本地提权漏洞，比丢失部分遥测数据危险得多。
为什么微软选择"掀桌"而不是"打补丁"
传统的权限提升漏洞修复通常是在关键路径加校验：检查调用者身份、验证输入长度、限制可执行路径。但CVE-2026-20817的问题更深层——SvcElevatedLaunch这个功能的架构假设是"客户端可信"，而Windows服务的安全模型早已演进为"默认不信任"。
试图在不破坏现有功能的前提下加固代码，可能需要重写整个ALPC消息处理状态机。微软的决策逻辑很产品经理：维护成本、回归测试风险、未来漏洞暴露面，三者叠加后，"功能下线"成了最优解。
这种判断有先例可循。2021年PrintNightmare漏洞后，微软同样考虑过禁用Windows打印后台处理程序的部分功能，最终因企业依赖度太高而选择了加固方案。WER的崩溃上报功能相对边缘，"截肢"的代价可控。
GMO的研究员在技术分析报告中提到，他们在2025年11月向微软提交漏洞细节，2026年3月补丁发布。六个月的修复周期对于本地提权漏洞来说偏长，可能反映了微软内部对"如何修复"而非"是否修复"的争论。
最终代码层面的证据表明，微软甚至没尝试过半路方案——__private_IsEnabled()函数从命名到实现都是"永久关闭"的语义，没有预留未来重新启用的配置接口。
对防御方的实际影响
对于已经打补丁的系统，这个攻击向量彻底消失。但安全团队需要关注两个衍生问题：一是旧版本Windows的漏洞状态，二是WER功能缩减后的监控盲区。
微软的安全公告确认，Windows 10 22H2、Windows 11 23H2/24H2及对应服务器版本均受影响。Windows 7和8.1早已停止支持，但如果企业环境仍有遗留系统，CVE-2026-20817构成了切实的横向移动风险——攻击者拿到普通用户凭证后，可借此漏洞获取域控级别的权限。
功能移除带来的副作用是崩溃日志收集机制的变化。部分企业安全产品依赖WER生成的转储文件进行威胁狩猎，补丁后可能需要调整监控策略，转向ETW（事件追踪）或其他遥测源。
攻击者社区对这类"功能级漏洞"的反应通常很快。微软补丁发布后72小时内，GitHub上已出现针对未修复系统的概念验证代码修改版——虽然原始PoC未公开，但二进制diffing足以让有经验的攻击者复现利用链。
你的终端防护策略里，WER服务的ALPC端口访问是否被列入了监控清单？还是说它和其他几百个系统服务一样，淹没在噪声里从未被仔细审计过？
热门跟贴