文章总结： 文档深度解析CVE-2026-49176，WindowsWalletService本地提权链。漏洞源于服务以调用者身份解析Documents路径后切换至SYSTEM打开数据库，结合ESE持久化回调机制，普通用户可构造恶意数据库实现提权。分析覆盖影响范围、触发条件及修复建议，强调版本基线核对与登录策略评估。
综合评分： 88
文章分类： 漏洞分析,红队,渗透测试

CVE-2026-49176 深度解析：Windows WalletService 本地提权链

Ots安全

2026年9月20日 13:22
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁简报

恶意软件

漏洞攻击

2026 年 7 月 14 日，微软发布了本年度规模最大的一批安全更新。BleepingComputer 在当日报道里给出的数字是 570 个漏洞，其中 59 个定级为 Critical，创下该媒体的统计口径纪录。这批更新里有一条本地提权漏洞，编号 CVE-2026-49176，厂商定级 Important，评分 7.8。

三天后，一位独立研究者发布了它的完整利用开发笔记；而配套的 PoC（Proof of Concept，概念验证）仓库，在补丁发布后第二天就已经上线。笔记的结论是，一个标准用户可以从自己的普通账户起步，取得 NT AUTHORITY\SYSTEM 权限的交互式命令行。链条的关键不在内存布局，也不在竞态窗口，而在一个数据文件里存着的一行模块路径。

这篇要处理的问题是，这句话里哪些部分能在公开材料里逐字核到，哪些部分只有一个来源。

一、先看问题：编号、评分与时间线

1.1 四个来源对同一件事的说法

厂商侧材料的完整度在这次是比较高的。MSRC 更新指南给出定级 Important、baseScore 7.8、temporalScore 6.8，向量为 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C，弱点两项是 CWE-269（权限管理不当）与 CWE-59（访问文件前链接解析不当）。受影响产品端点一次给出 23 条记录，每条都带知识库编号与修复构建号。致谢栏指向 STAR Labs SG。

1.2 事件时间线

| 日期 | 事件 | 相对补丁日 |
| — | — | — |
| 2026-05-27 | 编号保留 | 前 48 天 |
| 2026-07-14 | 补丁日发布，编号公开 | 第 0 天 |
| 2026-07-15 | 分析师富化块给出可利用性判定 | 第 1 天 |
| 2026-07-16 | 研究者 PoC 仓库创建 | 第 2 天 |
| 2026-07-17 | 研究者技术笔记发布 | 第 3 天 |
| 2026-07-20 | PoC 仓库最近一次推送 | 第 6 天 |
| 2026-07-29 | 可集成攻击框架组件仓库创建 | 第 15 天 |
| 2026-09-18 | 已知被利用漏洞目录版本，未收录本编号 | 第 66 天 |

从 PoC 公开到出现可直接装进现成攻击框架的封装，间隔 13 天。从补丁日算起，15 天。

值得注意的是这条时间线的顺序：修复在前，公开在后。这与常见的”先有在野利用、后有补丁”相反。它引出的是一个不同的处置问题，第五章会回到这一点。

二、影响范围：四处判定与九条构建基线

2.1 Documents 已知文件夹是否由当前用户自行控制

这条链的起点是一个 Windows 的常规能力：任何用户都可以改写自己账户下若干已知文件夹的落点。微软 Shell 文档在 SHSetKnownFolderPath 的备注里写得明确，对于每用户已知文件夹，调用者只需要 User 权限；同一段举的例子正是 Documents。

也就是说，把”文档”目录指到一个自己可写的位置，不需要管理员权限，不需要弹窗，也不需要改动任何受保护的系统位置。这是操作系统的既定设计，不是缺陷。

这条判定的结论是：起点不是门槛。 它把风险集中到下一处，即服务如何处理这个被改写过的路径。

2.2 构建号是否落在所在产品线的修复号之前

判定方法只有一条，对照上表：取目标系统自身的文件版本号，与该产品线的修复构建号比较。

Windows 11 25H2 的边界是 10.0.26200.8875，24H2 是 10.0.26100.8875，26H1 是 10.0.28000.2525，Server 2025 是 10.0.26100.33158。低于这些数值的同一基线系统，属于未修复状态。

这条判定有一个容易踩空的地方：产品显示名与构建基线的对应关系常被写错。中文侧一份转述把它写成「Windows 11 22H2（Build 26100.0）」与「Windows 11 24H2（Build 26200.0）」，而按厂商清单，26100 对应 24H2、26200 对应 25H2，且清单里并不存在 Windows 11 22H2 这个条目。

版本名认错，构建号就会认错，自查结论就会反。 拿不准时以构建号区间为准，不以产品显示名为准。

2.3 目标系统是否随附 WalletService 组件

WalletService 为公开的 Windows.ApplicationModel.Wallet 这一组 WinRT（Windows Runtime）接口提供后端支持，在补丁日的这批更新里，它与 Windows 的客户端与服务器产品线同时出现在受影响清单中。

研究者笔记里有一个实测细节值得记下：从标准桌面进程直接激活 Wallet 的私有 COM 类会被能力门挡住并返回 E_ACCESSDENIED，但公开的 Wallet 接口会执行受支持的激活流程，并进入同一条特权初始化路径。

这意味着”能不能直接调私有接口”不是判定项。 公开接口已经够用，能力门拦的是路径而不是结果。

2.4 是否存在多位本地用户的共用终端

该漏洞的前置是”攻击者已在目标机上持有一个本地账户”。因此暴露面集中在那些允许不受信任账户本地登录的环境：共用工作站、多用户终端、虚拟桌面池、自助服务终端。

单用户的个人设备上，链路的前提是攻击者已经拿到了这个账户，此时本地提权的边际价值取决于该账户的权限余量。同一漏洞在不同环境里的实际值差异很大，这一条不靠版本号判断，靠登录策略判断。

三、原因导致：一次身份切换与一个默认关闭的参数

3.1 从调用者身份取路径

研究者给出的调用次序是一条标准的模拟链：服务先取得调用者令牌，解析该令牌对应的 Documents 已知文件夹，然后恢复自身身份。涉及的四步是 CoImpersonateClient、OpenThreadToken、SHGetKnownFolderPath(FOLDERID_Documents, 调用者令牌) 与 CoRevertToSelf。

关键在于第四步之后的动作：服务把 \Wallet\ 追加到刚解析出来的路径上，然后以 LocalSystem 身份打开 wallet.db。

到这一步为止，每一句都还是常规写法。 服务确实需要知道调用者的数据目录在哪，也确实需要在打开文件时以自身身份访问。问题出在两件事的接缝，而不出在任何一件事本身。

3.2 回到自身身份之后才打开

研究者的原话把这个接缝说得很清楚，先引原文：

The service uses caller-derived identity state to select a pathname, then crosses back into LocalSystem before deciding what the object at that pathname may contain.

译作：服务使用由调用者派生的身份状态来选定一个路径名，随后在判断该路径名下的对象可以包含什么内容之前，切换回 LocalSystem 身份。

换一种说法：路径是由调用者的权限级别选出来的，而对路径下对象的取舍，是在最高权限级别上做的。 调用者既能决定这个目录在哪里，也能决定这个目录里预先放着什么。

需要标明的是，机制描述的这一层只有研究者一个来源。厂商公告未涉及实现细节，组件闭源且没有可逐行比对的补丁，本文无法在公开材料范围内独立复核这两句。

3.3 ESE 的持久化回调是什么

下一环涉及 ESE（Extensible Storage Engine，Windows 的可扩展存储引擎）。该引擎支持在列的 schema 里保存一个回调说明，形如 模块路径!导出函数名。

这一步可以在微软文档里核到。JET_USERDEFINEDDEFAULT 结构的 szCallback 成员说明写着，模块名与函数名会被数据库引擎在运行时用来定位回调的真实地址，方式是先对模块名执行一次 LoadLibrary，再对函数名执行一次 GetProcAddress。

这就把一个数据文件变成了加载指令。 引擎不是在读一段数据，而是在按文件里写的地址去装载一个模块并调用一个导出函数。文档还写明，这条信息随列 schema 持久保存，因此它跟着数据库走，不需要运行期另行注入。

3.4 厂商文档里那句安全警告

同一页文档里有一段针对该能力的安全说明，原文如下：

The application should pass only trusted callbacks to the database engine. The database engine will load the binary to verify its existence when the associated column is created. If the path to the binary is not validated or known to be trusted then it could attack the process that is hosting the database.

译作：应用只应向数据库引擎传递可信的回调。数据库引擎会在创建关联列时加载该二进制以验证其存在。如果该二进制的路径没有被校验，或者不被确知可信，那么它就可能攻击承载该数据库的进程。

文档另有一段补充：强烈建议使用模块名的完整路径，如果使用相对路径，承载该数据库的进程可能易于受到一个流氓二进制（rogue binary）的攻击。

这两段是本篇证据强度最高的一处。 它把”这个能力会攻击宿主进程”从推断变成了引用，而且是被攻击的那一侧自己写下的。它同时说明，放行与否的判断标准本来就存在，判据是”这个路径是否可信”；缺陷在于这一次，那个路径来自调用者。

3.5 参数默认状态与仍然可以写进 schema

还有一处细节解释了攻击者为什么能在低权限一侧把载体准备完整。

JET_paramEnablePersistedCallbacks 这个引擎参数（编号 156）默认值为 False。文档写明，在 Vista 之前的版本中持久化回调是默认启用的，现在的应用必须在运行时显式开启；如果不设置该参数，任何需要调用回调的数据库操作都会失败并返回 JET_errCallbackFailed。

同一段紧接着一句更关键的话：

It is still possible to create schema elements that contain persistent callbacks even when the use of those persistent callbacks is disallowed.

译作：即便持久化回调的使用被禁止，仍然可以创建包含持久化回调的 schema 元素。

这两句合起来的含义是：载体的构造不需要任何特权。 一个普通用户在自己的目录下创建一个带回调说明的数据库，引擎不会拦；而是否真正触发加载，取决于承载方有没有打开那个开关。开关在服务那一侧。

这里要标出边界：服务确实打开了这个开关，是研究者单方给出的。 本文在本篇公开材料范围内未能找到第二个来源。

3.6 缺陷已经具备的四个条件

把前面几节并起来，这条链成立需要同时满足四点。

| 条件 | 来源 | 本次状态 |
| — | — | — |
| 用户可自行改写自己的 Documents 落点 | 微软 Shell 文档 | 成立，且不需要管理员权限 |
| ESE 会按 schema 里写的路径加载模块 | 微软 ESE 文档 | 成立，机制为 LoadLibrary |
| 引擎不校验该路径是否可信，文档要求应用自己校验 | 微软 ESE 文档 | 判定责任落在应用侧 |
| 承载方开启了持久化回调，且接受调用者派生路径下的数据库 | 研究者 | 单方来源 |

前三条是引擎与操作系统的既定行为，不是缺陷本身。 第四条才是这次的接缝。也就是说，问题不在于某个能力太强，而在于一个高权限承载方在自己无法保证可信的位置上，开启了那个能力。

四、漏洞触发：从数据库到 SYSTEM 会话

4.1 预置一份最小数据库

研究者的构造思路是先把载体做小：在标准用户可写的目录下建一个私有 ESE 实例，创建 wallet.db，建一张名为 Cards 的表，再给这张表加一个带用户自定义默认值的列，列里保存回调模块的路径与导出函数名，然后干净地关闭引擎，留给服务稍后打开。

Cards 这个表名不是任意选的，它是 Wallet 的强制表名，服务初始化时会去访问它。这一点决定了后面触发只需要一次常规调用。

有一个布置细节值得记下：回调模块与投递组件放在 Wallet 目录之外的兄弟目录里。原因是修复前的服务会把 Wallet 子目录的访问控制列表替换为 SYSTEM 与 Administrators 完全控制，把可执行组件留在那个受限子目录之外，才能让服务宿主读到它们。研究者注明，这些文件在攻击者自己的测试根目录内仍然只有本人可写。

这类”布置约束”通常是判断一个 PoC 是否真的跑通过的最好线索，因为它是被实测环境逼出来的，不是设计出来的。

4.2 三条被排除的路线

研究者的笔记里记了三条走不通的路，这三条比结论本身更能说明边界。

第一条是整目录的联接（junction）。WalletDatabaseESE::LoadDatabase 会打开 Wallet 根目录，调用 GetFinalPathNameByHandleW 取回解析后的路径，再与传入路径比对。联接在进入有用的 ESE 路径之前就会失败。

第二条是 Wallet 的图像属性。基于文件的图像源可以到达形如 <Documents>\Wallet\Photos\{服务生成的 GUID}.{源扩展名} 的路径，字节内容与扩展名都可控，但基础文件名是一个新生成的 GUID，且没有任何服务代码会执行这个文件。

第三条是包导入。图像目标使用随机 GUID 名并强制 .png 后缀，对直接执行来说更弱。

三条路排除掉之后剩下的是同一个判据：这一环必须同时给出已知的可执行文件名，以及一个会自动以 SYSTEM 身份消费它的组件。 ESE 路径之所以成立，正是因为它同时满足这两点。研究者自己对此的表述是，链不依赖竞态、内存破坏、符号链接权限或对服务二进制路径的猜测。

4.3 触发只用到一次枚举调用

触发侧用到的是公开接口，次序是 WalletManager.RequestStoreAsync() 取得存储对象，随后调用 GetItemsAsync()。

按常规用法，GetItemsAsync() 是在枚举钱包条目。研究者的观察是，服务初始化会在条目枚举正常完成之前先打开数据库并访问 Cards 表，因此这一次调用已经足够。

触发脚本会把原始的 Documents 位置记下来，改成攻击者控制的运行根目录，并在一个 finally 块里恢复原状。

恢复动作不依赖利用是否成功。 无论跑在漏洞版本、修复版本，还是利用失败，配置都会回到原位。这个设计降低了它在目标机上留下的持久痕迹，同时也说明研究者把”不改变目标状态”当成了交付标准。

4.4 第一级证明落在受保护文件里

第一版回调载荷被刻意做成非交互式：它把自己的进程身份写进一个受保护文件。研究者保存的运行记录是：

event=DLL_PROCESS_ATTACHpid=6232user=SYSTEMimage=C:\Windows\System32\svchost.exe

这个文件的所有者是 NT AUTHORITY\SYSTEM。从低权限账户直接向同一受保护目录写入的尝试会失败并返回访问被拒绝。

这组对照排除了两种误读。 一是父进程假设，即认为写出这些内容的可能是触发者自己；二是低完整性标记，即认为文件可能是由触发进程以某种方式凑出来的。能往 SYSTEM 属主目录里写东西的，只有 SYSTEM 身份的代码。

这一级的价值在于它把”代码在服务宿主内执行”从推断变成了留痕证据，而不需要依赖屏幕上出现一个命令行窗口。

4.5 第二级证明把令牌搬进交互会话

在服务宿主内获得代码执行，与在交互桌面上拿到一个命令行，是两件事。研究者把这两件事分开处理了。

回调载荷先校验自己的令牌是否为 WinLocalSystemSid，确认后创建一个指向投递组件的临时服务，启动它，随即删除服务注册。投递组件因此拿到一个常规的 LocalSystem 服务令牌，具备投递到桌面所需的权限。随后的动作是：用 WTSGetActiveConsoleSessionId 与 WTSEnumerateSessionsW 找到活动的交互会话，把 SYSTEM 令牌复制为主令牌，把 TokenSessionId 改为该会话，选择 winsta0\default，再调用 CreateProcessAsUserW 启动 cmd.exe。

研究者注明，无管理员权限的验证过程在运行结束后没有留下临时服务残留，最终得到的 shell 运行在会话 1，身份为 NT AUTHORITY\SYSTEM。

链条每一段各自承担一个可独立验证的声明，研究者自己列了这张对应关系：调用者控制 Documents 映射，说明用户控制服务使用的父目录；预置的 wallet.db，说明用户控制服务消费的 schema；持久化回调被解析，说明引擎在 SYSTEM 宿主内加载了攻击者选定的模块；回调内的身份校验，确认代码确实以 LocalSystem 执行；临时投递服务，取得一个干净的服务令牌用于桌面投递；会话感知的 CreateProcessAsUserW，产出可见的 SYSTEM 命令行。

这个分层方式值得单独记一笔。 它把一个容易混作一团的结论拆成了六个各自可以否证的声明，任何一段不成立时，读者能准确知道断在哪里。

五、补丁分析：五个提前返回的函数

5.1 修复被放在一个服务特性开关上

研究者对修复前后两个构建做了补丁比对，把修复定位到一个服务特性上：

Feature_Servicing_WalletServiceRedirectionGuardinternal feature ID: 3305877819

这属于研究者单方给出的结论，本文无法独立复核该特性名与编号。能否复核的部分是结果：厂商清单里 Windows 11 25H2 的修复构建号是 10.0.26200.8875，与研究者用作对照的版本一致。

“修复被放在一个特性开关上”这个说法本身值得留意。 它的含义是修复的形态偏向于关停旧路径，而不是在旧路径里补一段校验。

5.2 哪些操作被跳过

研究者列出修复构建里被守卫的五个操作：

| 函数 | 修复后的行为 |
| — | — |
| WalletDatabaseESE::Open | 在打开 ESE 数据库之前返回 |
| ServerUtils::HideAndRestrictFolder | 跳过旧版文件夹限制 |
| RestrictFolder | 跳过对目录访问控制列表的替换 |
| FileUtils::DeleteFiles | 跳过旧版清理删除 |
| WalletDatabaseESE::HandleDatabaseCorruption | 跳过损坏清理 |

从这份清单能读出的因果很直接：数据库不再被打开，回调就不会被解析，模块就不会被加载。 这是一条有效切断，因为链条的其余部分都挂在这一步之后。

5.3 修复后仍留下的那部分

研究者给了一个精确的前后差异，这一处特别值得抄下来。

在漏洞构建 26200.8737 上，一次 GetItemsAsync() 会让 LocalSystem 创建一个 <选定父目录>\Wallet\，把该子目录的访问控制列表替换为 SYSTEM 与 Administrators 完全控制，并创建完整的一套 ESE 文件，包括 edb.chk、edb.log、edbres00001.jrs、edbres00002.jrs、edbtmp.log、wallet.db 与 wallet.jfm。

在修复构建 26200.8875 上，同一次调用只创建一个空的 Wallet 目录，权限为继承，没有 ESE 文件出现，也没有施加限制性访问控制列表。

研究者对此的说明是，目录的创建发生在被守卫的 ESE 打开之前，因此修复后仍会留下一个空目录。

一条看起来”没修干净”的残留，其实是守卫位置的结果，不是漏修。 它的实际意义是给排查留下了一个可观察的前后差异：修复后仍可能出现空 Wallet 目录，但其中不应出现任何 ESE 文件。

5.4 判读补丁层时的边界

本篇在补丁这一层有一定局限，需要写明。

组件是闭源的，没有公开的补丁提交可逐行比对。上面五个函数的修复后行为清单，以及特性名与内部编号，全部来自研究者的比对结论，本文无法在公开材料范围内复核。因此本章的表述方式一律是”研究者给出的比对结论为”，而不是”修复方式是”。

这一点直接限制了可下的结论：本文能确认的是修复已随 7 月更新发布、修复构建号是多少、修复后差异是什么；本文不能确认的是补丁修改了哪几行、该特性开关的默认状态与启用条件。 后者如果由第三方逆向另行验证，结论可能更细。

5.5 同一组件在 2026 年的三条提权编号

WalletService 在同一年的七个月里被记入三条提权编号，全部来自厂商清单，可逐条核对。

| 编号 | 发布日 | 向量要点 |
| — | — | — |
| CVE-2026-20853 | 2026-01-13 | PR:N，无需任何权限 |
| CVE-2026-32080 | 2026-04-14 | AC:H，攻击复杂度高 |
| CVE-2026-49176 | 2026-07-14 | PR:L，AC:L |

三条的定级都是 Important，exploited 字段都是 No，可利用性评级都是 “Exploitation Less Likely”。

这三条的根因分别落在竞态、内存生命周期与路径信任三类上，互不相同。 同一组件在一年内被三个不同方向的问题击中，说明的不是某一个函数写错了，而是这个组件承载的信任假设比较多：它要处理调用者身份、调用者路径与调用者提供的数据库，三样东西都来自低权限一侧。

需要留一句边界：这只能说明该组件的披露密度较高，不能据此推断它的实际风险高于其他组件。厂商对三条都给出了相同的可利用性评级。

5.6 从 PoC 到可集成组件用了十三天

时间线里已经摆出的一个数字，值得单独说：研究者 PoC 仓库创建日（2026-07-16）到可集成组件仓库创建日（2026-07-29）之间隔了 13 天，从补丁日算起是 15 天。

后者的公开描述写明它是一个可从中等完整性会话（即标准用户）直接使用的本地提权工具，会完成载体的布置、Documents 的重定向、服务的触发，并在交互会话里以 NT AUTHORITY\SYSTEM 运行指定的命令行。这已经不是验证性脚本，而是可以直接装进现成攻击框架的模块。

这条链的公开顺序决定了它的现实风险形态： 补丁已经发布，但存量系统不会在一周内全部更新。PoC 在补丁后两天公开，等于给尚未更新的系统提供了一份现成的利用路径，而 15 天后出现的封装又把这个门槛降了一档。

换言之，这份披露的威胁不在于它是否被在野利用过，而在于它把”补丁已发布”与”补丁已安装”之间的时间差变成了可利用窗口。

六、结束语

这次披露有一个不常见的次序：修复在前，利用在后。补丁发布时该漏洞既未被在野利用，也未被公开披露，厂商按常规给了 Important 与 7.8 分；两天后，完整的 PoC 上线；15 天后，可集成组件出现。

这个次序把本地提权类漏洞的处置逻辑摆得更清楚了。这类漏洞本身不提供初始入口，它改变的是入口之后的权限余量。真正决定风险的不是补丁是否发布，而是补丁发布到安装之间的那段窗口，以及这段窗口里有多少台机器允许低权限账户本地登录。

本篇留下两条待外部复核的项：机制描述与修复形态均只有一个来源，本文已逐处标注；该披露的机制部分未获厂商确认，这不构成异常，闭源组件不提供机制说明是常态，而厂商本次在定级、范围、修复号与致谢四项上是完整的。

一条链能否成立，取决于几个条件是否同时出现；而防御要做的，是让其中任意一个条件无法同时满足。 就本例而言，最靠近根因的那一个是：不以最高身份去打开一个由较低身份选定了位置的数据库。

七、参考

厂商公告（MSRC 更新指南）https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-49176受影响产品清单（含知识库编号与修复构建号）https://api.msrc.microsoft.com/sug/v2.0/en-US/affectedProduct?$filter=contains(cveNumber,'CVE-2026-49176')
编号记录CVE.org 记录页https://cve.org/CVERecord?id=CVE-2026-49176CVE.org 记录接口https://cveawg.mitre.org/api/cve/CVE-2026-49176NVD 详情页https://nvd.nist.gov/vuln/detail/CVE-2026-49176
厂商文档ESE 回调参数（含 JET_paramEnablePersistedCallbacks）https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/callback-parametersJET_USERDEFINEDDEFAULT 结构（含 szCallback 与安全说明）https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/jet-userdefineddefault-structureSHSetKnownFolderPath 函数（每用户已知文件夹的权限要求）https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shsetknownfolderpath
研究者材料技术笔记：CVE-2026-49176 Exploit Development: WalletService toSYSTEMhttps://davidcarliez.github.io/blog/cve-2026-49176-walletservice-to-system/PoC仓库：DavidCarliez/CVE-2026-49176_LPE_POC（创建于2026-07-16）https://github.com/DavidCarliez/CVE-2026-49176_LPE_POC可集成组件仓库（创建于2026-07-29）https://github.com/777erp/CVE-2026-49176_BOF
同一组件同期编号CVE-2026-20853（2026-01-13，CWE-362）https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20853CVE-2026-32080（2026-04-14，CWE-416）https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32080
在野状态已知被利用漏洞目录（2026-09-18 版本，未收录本编号）https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
补丁日背景MicrosoftJuly2026 PatchTuesdayfixesmassive570flaws,3zero-days，BleepingComputer，LawrenceAbrams，2026-07-14https://www.bleepingcomputer.com/news/microsoft/microsoft-july-2026-patch-tuesday-fixes-massive-570-flaws-3-zero-days/

END

公众号内容都来自国外等平台- 搜索的内容通过结合编写 –

 提供整洁 – 广告已关

公众号 | AnQuan7 (Ots安全)

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Ots安全 《CVE-2026-49176 深度解析：Windows WalletService 本地提权链》