Windows AppResolver 本地提权漏洞深度解析:从 AppContainer 到 SYSTEM 的完整攻击链
近期安全圈引起不小波澜的一则技术披露来自研究员 David Kalish 对 Windows 系统底层组件的深入挖掘。他在 GitHub 上公开了一套完整的概念验证代码展示了一条从低权限 AppContainer 一路攀升至 SYSTEM 权限的本地提权路径。这条路径的核心正是 Windows.UI.Storage.dll 中一处被遗漏的功能检查——微软已在 2026 年 7 月的安全更新中将其封堵相关漏洞编号指向 CVE-2026-50454。UAC 这道防线被绕过后意味着什么很多普通用户对 UAC用户帐户控制的印象停留在那个烦人的弹窗但在安全架构里它实际上是 Windows 最核心的信任边界之一。大量攻击在抵达真正敏感的操作之前都会被 UAC 这道关卡拦下。一旦能够干净利落地绕过它攻击者就能以完整的管理员权限执行代码全程不需要任何用户点击是的确认提示。到了这一步获取 SYSTEM 权限基本就是顺水推舟的事了。David Kalish 将他的发现连同 PoC 一并发布到了 GitHub 上。代码公开之后防御方和攻击方都能拿到手研究——这通常是双刃剑。公开的漏洞利用代码往往会大幅缩短从理论到实战的时间窗口。不过截至目前还没有任何公开报告证实该漏洞已在真实环境中被大规模利用。这里需要澄清一个关键前提这不是一个普通用户直接拿到 SYSTEM的漏洞。发起攻击的账户本身必须是本地管理员组的成员只是当前以经过过滤的标准令牌在运行。正常情况下UAC 会阻止这个过滤令牌执行高权限操作而这条攻击链的精妙之处就在于它绕过了这层阻拦。漏洞的底层机理问题的根源藏在一个用于构建 AppResolver 对象的私有 WinRT 类里。在存在漏洞的版本中一个几乎没有任何能力的零权限 AppContainer居然可以直接调用这个工厂接口而系统完全没有做必要的权限校验。被突破的安全边界不是管理员权限本身而是 AppContainer 的隔离检查。在这个漏洞链中这个原语的作用是充当跳板目的是绕过 UAC而不是凭空赋予管理员身份。攻击者首先需要注册一个自定义的协议处理程序然后将其设置为 ms-settings 协议的受保护默认值。接下来自带自动提升权限属性的 fodhelper.exe 会去解析这个协议。由于处理程序已经被篡改fodhelper 会在高完整性级别下静默执行攻击者的代码全程不弹任何提示框。高完整性进程到手之后下一步是创建一个短暂存在的服务。Windows 的服务控制机制会以 SYSTEM 身份启动这个服务。PoC 的最终效果是在用户的桌面会话里弹出一个交互式的命令提示符权限已经是 SYSTEM 级别。研究人员只分享了机制层面的技术细节具体的漏洞利用步骤这里不再复述。受影响的系统范围这次 AppResolver 本地提权漏洞主要波及 Windows 11 的 25H2 版本在 2026 年 7 月累积更新发布之前均处于暴露状态。David Kalish 在版本 26100.8737 上成功复现了该漏洞。安装 2026 年 7 月补丁后的版本 26100.8875 已经修复了这个问题——当同样的攻击载荷被投递时系统会直接返回访问被拒绝的错误漏洞触发路径被彻底阻断。关于 CVE 编号的归属争议这里有一个值得细究的地方。微软官方公开的 CVE-2026-50454 漏洞记录描述的是相对路径遍历和文件删除问题。但 David Kalish 发布的概念验证代码并没有涉及这两项漏洞特征。相反他展示的是同一个组件中 AppResolver 功能检查的缺失而这个问题恰好也在同一个 7 月更新中被修复了。因此研究人员倾向于将其视为 2026 年 7 月补丁一并修复的 AppResolver 安全问题而非 CVE-2026-50454 公告中所描述的根本原因。企业端的应对建议最直接的修复方案就是安装 2026 年 7 月的 Windows 安全更新或者任何更高版本的累积更新。在已测试的环境中版本 26100.8875 确认包含了相关修复。如果企业想叠加深层防护可以考虑部署应用程序控制策略从链条的多个节点上进行拦截——比如限制 PowerShell 执行、阻止 AppContainer 的异常行为或者管控服务的创建流程。考虑到概念验证代码已经公开各安全团队应该把这个补丁的优先级往上提。攻击窗口期往往就发生在补丁发布后的几周内越早完成修复暴露面就越小。