作者 akihi（白帽攻防录讲师），某甲方网络安全工程师，合合 SRC 年度第一、腾讯 SRC 连续三年前十，单漏洞赏金 4w+，擅长 Web/App/PC 客户端漏洞挖掘。专注 Windows 服务安全、内存漏洞利用与暴露面测绘。本文基于公开 CVE 信息与技术原理深度复盘，供安全研究与防护参考。
一、漏洞时间线
2026 年 10 月 13 日，微软发布了 10 月月度安全更新，一次性修复了 1415 个漏洞，其中 85 个被标记为"严重"。在这堆漏洞中，有一个 CVSS 满分级别的网络远程代码执行漏洞格外醒目------CVE-2026-100202，存在于 Windows Message Queuing（MSMQ）队列管理器中，一个 Use After Free 漏洞，攻击者不需要认证、不需要用户交互，只要网络能访问到目标的 1801 端口，就能远程执行代码。
| 时间 | 事件 | 影响 |
|---|---|---|
| 2026-10-13 | 微软 10 月 Patch Tuesday 发布 | 修复 1415 个漏洞 |
| 2026-10-13 | CVE-2026-100202 公开披露 | CVSS 9.8，网络 RCE |
| 2026-10-13 | CVE-2026-108460 同时披露 | 同类 MSMQ UAF 漏洞 |
| 2026-10-14 | CISA KEV 评估中 | 暂未列入在野利用 |
MSMQ 是什么？它是 Windows 自带的消息队列服务，从 Windows 2000 时代就有了，用来在应用程序之间异步传递消息。问题是：很多企业根本不需要这个服务，但它在某些场景下被默认启用，或者被管理员不经意间打开了------而且它监听在网络端口上，不需要认证就能访问。这就像在互联网上开了一扇没锁的门。
二、攻击链全景
让我们先还原完整的攻击路径：
攻击者在互联网上扫描暴露 MSMQ 服务的主机
│
▼
第一步：暴露面发现
│ 攻击者做什么？
│ - 扫描 TCP 1801 端口
│ - 识别 MSMQ 服务指纹
│ - 确认目标版本有漏洞
│
│ MSMQ 暴露在哪里？
│ - 端口 1801（默认）
│ - 不需要认证
│ - 不需要用户交互
▼
第二步：发送特制 RPC 消息
│ 攻击者做什么？
│ - 通过 MSMQ RPC 协议发送消息
│ - 构造特殊的消息序列
│ - 触发 UAF 条件
│
│ UAF 怎么触发？
│ - 正常流程：分配对象 → 使用对象 → 释放对象
│ - 漏洞流程：分配对象 → 释放对象 → 再次使用对象
│ - 释放后内存被复用 → 攻击者控制内容
▼
第三步：堆喷射与内存控制
│ 攻击者做什么？
│ - 喷射大量堆对象
│ - 覆盖已释放内存
│ - 构造伪造的对象结构
│
│ 为什么能控制？
│ - UAF 留下了悬空指针
│ - 指针指向的内存被攻击者控制
│ - 程序误以为指针指向合法对象
▼
第四步：劫持执行流
│ 攻击者做什么？
│ - 伪造对象的函数指针
│ - 当程序调用虚函数时
│ - 跳转到攻击者 shellcode
│
│ 为什么能劫持？
│ - C++ 对象通过 vtable 调用方法
│ - 伪造 vtable 指向恶意代码
│ - 程序执行攻击者的指令
▼
第五步：获得 SYSTEM 权限
│ 攻击者做什么？
│ - MSMQ 服务以 SYSTEM 权限运行
│ - 直接获得系统最高权限
│ - 安装后门、窃取数据
▼
攻击者完成攻击并撤离
│
├─ 以 SYSTEM 权限执行任意代码
├─ 完全控制目标服务器
└─ 不需要任何认证和用户交互**关键结论：**CVE-2026-100202 的危险性在于它的暴露面------MSMQ 是一个网络服务，监听在 TCP 1801 端口，不需要认证就能访问。在 SRC 挖洞实践中，暴露面测绘是第一步：你找到那些不该出现在公网上的服务，它们往往就是赏金最高的漏洞入口。UAF 漏洞虽然利用难度较高，但一旦成功，就是从网络到 SYSTEM 的一键直达。
三、MSMQ 与 UAF 漏洞原理
3.1 什么是 MSMQ
Microsoft Message Queuing（MSMQ）是 Windows 的消息队列服务：
| 特性 | 说明 |
|---|---|
| 服务名 | MSMQ (Microsoft Message Queue) |
| 默认端口 | TCP 1801 |
| 运行权限 | SYSTEM |
| 协议 | MSMQ RPC / DCOM |
| 功能 | 应用程序间异步消息传递 |
| 是否默认安装 | 否（需手动启用 Windows 功能） |
| 历史漏洞 | CVE-2023-36910（同类 RCE） |
3.2 什么是 Use After Free
Use After Free（UAF）是内存破坏类漏洞中最常见的类型之一：
// 什么是 Use After Free？
// 正常的内存使用流程：
// 1. 分配内存：obj = malloc(size)
// 2. 使用内存：obj->do_something()
// 3. 释放内存：free(obj)
// 4. 指针不再使用
// UAF 漏洞流程：
// 1. 分配内存：obj = malloc(size)
// 2. 使用内存：obj->do_something()
// 3. 释放内存：free(obj)
// 4. 忘记把 obj 设为 NULL
// 5. 再次使用：obj->do_something() ← 这里出错了！
// 为什么危险？
// - free(obj) 后，那块内存被归还给堆管理器
// - 堆管理器可能把它分配给其他对象
// - 如果攻击者能控制新分配的内容
// - 那么 obj 指向的内存就被攻击者控制了
// - 程序以为 obj 还是原来的对象
// - 实际上执行的是攻击者的数据
// UAF 利用的关键步骤：
// 1. 触发漏洞，让对象被释放
// 2. 通过其他操作在同一块内存上分配新对象
// 3. 控制新对象的内容
// 4. 当旧指针被使用时，执行攻击者的逻辑3.3 MSMQ 为什么会有 UAF
// MSMQ UAF 漏洞原理
// MSMQ Queue Manager 处理消息的流程：
// 1. 接收网络消息
// 2. 创建消息处理对象
// 3. 处理消息
// 4. 处理完成后释放对象
// 漏洞在哪里？
// - 在特定的消息序列下
// - 对象被提前释放
// - 但处理线程还在引用这个对象
// - 导致 UAF
// 攻击者怎么利用？
// 1. 发送第一个消息，创建对象
// 2. 在处理过程中触发释放
// 3. 发送第二个消息，在同一块内存分配新对象
// 4. 新对象的内容由攻击者控制
// 5. 处理线程继续使用旧指针
// 6. 实际上操作的是攻击者的对象四、漏洞深度分析
4.1 CVE-2026-100202 技术细节
// CVE-2026-100202 漏洞分析
// 基本信息：
// - 漏洞类型：Use After Free
// - 影响组件：Windows Message Queuing Queue Manager
// - CVSS：9.8（Critical）
// - 攻击向量：Network（网络）
// - 攻击复杂度：Low（低）
// - 所需权限：None（无需认证）
// - 用户交互：None（无需用户交互）
// - 影响范围：Changed（影响范围扩大）
// - 机密性：High
// - 完整性：High
// - 可用性：High
// CVSS 向量：
// CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
// 为什么 CVSS 是 9.8？
// - 网络可达（AV:N）
// - 攻击复杂度低（AC:L）
// - 无需认证（PR:N）
// - 无需用户交互（UI:N）
// - 三大影响都是 High
// - 这是最严重的网络 RCE 配置
// 同时披露的 CVE-2026-108460：
// - 同类 MSMQ UAF 漏洞
// - CVSS 较低（攻击复杂度 High）
// - 说明 MSMQ 存在多处内存管理问题4.2 历史对比：MSMQ 的漏洞传统
| CVE 编号 | 年份 | 漏洞类型 | CVSS |
|---|---|---|---|
| CVE-2023-36910 | 2023 | MSMQ RCE | 9.8 |
| CVE-2026-100202 | 2026 | MSMQ UAF RCE | 9.8 |
| CVE-2026-108460 | 2026 | MSMQ UAF RCE | 较低 |
可以看到，MSMQ 不是第一次出安全问题了。2023 年就有一个满分 RCE，三年后又来两个。这说明这个老服务的代码质量一直有问题------它已经二十多年历史了，里面的内存管理逻辑可能早就腐化了。
4.3 影响范围
| 项目 | 详情 |
|---|---|
| CVE 编号 | CVE-2026-100202 |
| 漏洞类型 | Use After Free |
| 影响产品 | Windows Message Queuing Queue Manager |
| 攻击向量 | 网络（TCP 1801） |
| 认证要求 | 不需要 |
| 用户交互 | 不需要 |
| 运行权限 | SYSTEM |
| CVSS 评分 | 9.8（Critical） |
| 在野利用 | 暂未发现 |
4.4 为什么 MSMQ 会暴露在公网
// MSMQ 为什么会出现在公网？
// 原因一：管理员不知道它在跑
// - 某些应用安装时自动启用 MSMQ
// - 管理员没注意到
// - 防火墙规则没限制
// 原因二：测试环境忘记关
// - 开发测试时启用了 MSMQ
// - 测试环境直接暴露在公网
// - 没有及时关闭
// 原因三：云配置错误
// - 云服务器安全组放行 1801 端口
// - 误以为只在内网用
// - 实际整个互联网都能访问
// 原因四：遗留系统
// - 二十年前的企业应用
// - 依赖 MSMQ 通信
// - 系统一直在跑，没人维护
// - 但也没人敢关
五、修复方案分析
微软在 10 月 Patch Tuesday 中修复了这个漏洞。修复方式是在 MSMQ Queue Manager 的消息处理路径中增加了对悬空指针的检查和引用计数管理。
| 修复项 | 修复方式 |
|---|---|
| 内存管理 | 增加引用计数，确保对象释放后不再被使用 |
| 消息处理 | 修复消息序列处理中的竞态条件 |
| 指针安全 | 释放后将指针置空，防止悬空引用 |
5.1 临时缓解措施
// 临时缓解措施（不需要打补丁）
// 1. 禁用 MSMQ 服务
// - 如果不需要消息队列功能
// - 直接在 Windows 功能中关闭 MSMQ
// - 这是最彻底的防护
// 2. 防火墙阻断 1801 端口
// - 在 Windows 防火墙中入站规则
// - 阻止 TCP 1801 端口的外部访问
// - 只允许内网特定 IP 访问
// 3. 网络分段
// - 把运行 MSMQ 的服务器放在内网
// - 不要暴露在公网
// - 通过防火墙隔离
// 4. 检查是否真的需要 MSMQ
// - 很多系统用 MSMQ 是历史原因
// - 现在完全可以用 RabbitMQ/Kafka 替代
// - 评估后可以迁移并关闭 MSMQ5.2 暴露面分级
| 暴露级别 | 情况 | 风险 |
|---|---|---|
| 严重 | MSMQ 暴露在公网 + 未打补丁 | 可被远程 SYSTEM RCE |
| 高 | MSMQ 暴露在公网 + 已打补丁 | 服务指纹暴露，信息泄露 |
| 中 | MSMQ 在内网 + 未打补丁 | 内网横向移动风险 |
| 低 | MSMQ 在内网 + 已打补丁 | 风险可控 |
六、SRC 审计启示录
6.1 暴露面测绘清单
在 SRC 挖洞实践中，暴露面测绘是第一步。针对 Windows 服务的暴露面检查清单：
| # | 检查项 | 检测方法 |
|---|---|---|
| 1 | MSMQ (1801) | 扫描 TCP 1801 端口，识别 MSMQ 指纹 |
| 2 | SMB (445) | 检查 SMB 服务暴露和版本 |
| 3 | RDP (3389) | 检查远程桌面暴露 |
| 4 | WinRM (5985/5986) | 检查远程管理服务 |
| 5 | MSSQL (1433) | 检查数据库服务暴露 |
| 6 | IIS Web 服务 | 检查 Web 服务器版本和漏洞 |
6.2 UAF 漏洞审计要点
// UAF 漏洞审计要点
// 1. 查找释放后使用的代码路径
// - 搜索 free() / delete 后的指针引用
// - 检查异步回调中的对象生命周期
// - 关注多线程竞态条件
// 2. 关注网络服务的内存管理
// - 网络服务接收不可信输入
// - 每个连接创建对象
// - 对象释放时序容易出错
// 3. 检查引用计数
// - COM 对象用 AddRef/Release
// - 检查引用计数是否正确
// - 多线程下计数容易出错
// 4. 关注 C++ 虚函数调用
// - UAF 通常通过虚函数表劫持
// - 检查 vtable 指针是否可控
// - 这是 UAF 利用的核心6.3 Windows 服务安全检查清单
// Windows 服务安全检查清单
// 1. 禁用不需要的服务
// - 只运行必要的服务
// - 减少攻击面
// 2. 限制网络暴露
// - 不需要的服务不要监听网络
// - 用防火墙限制访问
// 3. 最小权限运行
// - 服务不要用 SYSTEM 权限
// - 用低权限服务账号
// 4. 及时更新
// - Windows Update 开启自动更新
// - 关键漏洞及时修补
// 5. 监控异常
// - 监控异常的网络连接
// - 监控进程创建和权限提升七、防护建议
- 立即打补丁：安装 10 月 Windows Update，修复 CVE-2026-100202
- 检查 MSMQ：检查服务器是否启用了 MSMQ，不需要就禁用
- 端口审计：用端口扫描工具检查公网暴露的 Windows 服务端口
- 网络分段：把内部服务放在内网，不要暴露在公网
- 最小权限：服务账号用最小权限，即使被攻破损失也有限
- 监控告警：监控 1801 端口的异常连接和可疑 RPC 请求
八、总结
CVE-2026-100202 是 2026 年 10 月 Patch Tuesday 中最危险的网络 RCE 漏洞之一------CVSS 9.8，无需认证，无需用户交互，通过 MSMQ 服务直接打到 SYSTEM 权限。这个案例告诉我们几件重要的事：第一，暴露面测绘是 SRC 挖洞的基本功------那些不该出现在公网上的服务（MSMQ、SMB、RDP、数据库），往往就是赏金最高的漏洞入口；第二，老服务的代码质量是定时炸弹------MSMQ 从 Windows 2000 跑到现在，二十多年的代码积累了大量内存管理问题，一个 UAF 就能把整个服务器打穿；第三，内存漏洞虽然利用门槛高，但一旦成功就是一键 SYSTEM------对于 SRC 来说，发现暴露的高危服务就是拿到了入场券，漏洞利用只是时间问题。在实战中，我经常用资产测绘工具扫描企业的暴露面，发现那些"藏在角落里"的服务------它们往往不是主力业务系统，但因为运维人员不熟悉、不关注，反而成了最薄弱的环节。MSMQ 就是典型：一个二十年前的老服务，没人用了，但也没人关，还开在网络端口上，等着被攻击。这个漏洞也提醒所有企业：做安全不是只盯着 Web 应用和防火墙，那些后台跑着的 Windows 服务、那些你以为"没人会注意"的端口，才是真正的隐患。
