文章目录
-
- 前言
- [1. 一个句点搞出来的大事](#1. 一个句点搞出来的大事)
-
- [1.1 事情是怎么炸出来的](#1.1 事情是怎么炸出来的)
- [1.2 CVSS 8.8 是什么概念](#1.2 CVSS 8.8 是什么概念)
- [2. 那个埋了几十年的坑](#2. 那个埋了几十年的坑)
-
- [2.1 Windows 的老毛病](#2.1 Windows 的老毛病)
- [2.2 两层理解不一致](#2.2 两层理解不一致)
- [3. Copilot 的安全检查怎么被绕过去的](#3. Copilot 的安全检查怎么被绕过去的)
-
- [3.1 白名单机制的 bug](#3.1 白名单机制的 bug)
- [3.2 CWE-94 的经典变体](#3.2 CWE-94 的经典变体)
- [4. 完整攻击链路拆解](#4. 完整攻击链路拆解)
-
- [4.1 第一步：埋 prompt](#4.1 第一步：埋 prompt)
- [4.2 第二步：Copilot 中招](#4.2 第二步：Copilot 中招)
- [4.3 第三步：路径截断](#4.3 第三步：路径截断)
- [4.4 第四步：命令执行](#4.4 第四步：命令执行)
- [5. 影响范围和修复情况](#5. 影响范围和修复情况)
-
- [5.1 谁中招了](#5.1 谁中招了)
- [5.2 修复了什么](#5.2 修复了什么)
- [5.3 赏金是多少](#5.3 赏金是多少)
- [6. AI 工具的安全边界问题](#6. AI 工具的安全边界问题)
-
- [6.1 新的攻击面](#6.1 新的攻击面)
- [6.2 开发者该怎么加固](#6.2 开发者该怎么加固)
- [7. 最后说几句](#7. 最后说几句)
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/HHX_01
前言
先问大家一个问题：你见过最离谱的安全漏洞是啥？
是那种挖了半天内存破坏、堆喷射的硬核 exploit？还是绕了十八个弯的逻辑漏洞？
今天聊的这个，连 exploit 都算不上------就是一个句点，把微软 Copilot 的安全机制给干翻了。
1. 一个句点搞出来的大事
1.1 事情是怎么炸出来的
微软有个安全研究员叫 Johann Rehberger，这人平时就爱琢磨各种稀奇古怪的漏洞。
有一天他在 X 上发了条推文，配了张图，就问了一句：「这代码有啥毛病？」
底下一群人看了半天，说这不挺正常的吗？路径也对，权限也对，逻辑也没问题啊。
结果这位老兄微微一笑：这玩意能绕过 Copilot 的全部安全检查，直接往受保护的配置文件里写东西。
全网：？？？
1.2 CVSS 8.8 是什么概念
这个漏洞编号 CVE-2026-103572，CVSS 评分 8.8。
可能有人对这个分数没概念，这么说吧------满分 10 分，7 分以上就是高危，9 分以上是严重。
8.8 分是什么水平？就是那种你公司 CISO 看到会从椅子上跳起来的水平。
影响范围呢？Visual Studio Copilot、SQL Server Management Studio，全在中招名单里。
表面上看，是一个安全功能被绕过了。但深挖下去你会发现------锅根本不在 AI 身上，在 Windows 身上。
2. 那个埋了几十年的坑
2.1 Windows 的老毛病
Windows 解析路径的时候，有个祖传毛病------文件名末尾的点号，它会静默给你截掉。
这事得从 DOS 时代说起。当年的短文件名规范不允许文件名以点号结尾，因为会跟「文件名.扩展名」的格式搞混。
那怎么办？Windows 内核想了个招：我在底层帮你自动去掉不就完了？
于是这一去，就去了几十年。
所有应用程序都不用管这事，你写 CreateFile 也好，_wfopen 也好，.NET 的 File.Open 也好，传进去一个带末尾点号的路径，内核层自动给你截了。
听起来挺贴心对吧？贴心到差点把 Copilot 给坑死。
2.2 两层理解不一致
问题出在哪？出在「两层行为不一致」。
系统文件层写入的时候，会截断末尾点号。但应用层做安全检查的时候，没做同样的处理。
举个具体例子：Copilot 想往这个路径写东西------
C:\Users\xxx\.vscode\settings.json.注意最后那个点。
安全检查一看：哟，这文件名带个点尾巴，不像是正经的配置文件路径嘛。行，放行。
结果 Windows 真正执行写入的时候，点号被截掉了。最终落盘的路径变成了------
C:\Users\xxx\.vscode\settings.json这是一个被严格保护的配置文件，本来是绝对不让写的。
安全检查以为在写 A，实际写的是 B。
你说这找谁说理去？检查站的人下班了，金库的门却开了。
3. Copilot 的安全检查怎么被绕过去的
3.1 白名单机制的 bug
Copilot 的安全机制，对 settings.json 这类敏感文件是有拦截规则的。
逻辑很简单：我维护一个白名单，在名单里的路径才能写，不在的就拦住。
思路没问题对吧？问题出在「怎么判断路径」上。
Copilot 的检查，是拿路径字符串自己做的判断------我看看这个字符串在不在白名单里。
它没去调 Windows 的文件系统 API，没让操作系统帮它做一次真实的路径解析。
这就好比你查身份证，只看了一眼照片，没去派出所核实。结果人家拿了个 P 过的证，你还真给放行了。
3.2 CWE-94 的经典变体
从 CWE 分类来看，这个漏洞属于 CWE-94------代码生成控制不当。
但更准确地说，这是一个路径规范化缺失导致的安全特性绕过。
最危险的漏洞从来都不是代码写错了。代码写错了，测试能测出来，fuzz 能跑出来，静态扫描能扫出来。
最危险的是两个系统对同一件事的理解不一样。
Copilot 的安全检查层觉得：这个路径不在保护列表里，可以写。
Windows 的路径解析层觉得：这个路径就是 settings.json，我给你存进去。
两边都「对」，两边都按自己的逻辑办事，结果凑一起就出事了。
这就是系统集成里最难搞的一类 bug------跨层边界的一致性问题。你说谁错了？谁都没错，但合起来就是错了。
4. 完整攻击链路拆解
4.1 第一步：埋 prompt
攻击链不复杂，甚至可以说有点朴素。但就是这种朴素的攻击，往往最致命。
第一步，攻击者先在某个地方埋一个恶意 prompt。
埋哪？PR 描述里。Issue 评论里。甚至代码注释里都行。
只要用户打开这个项目，Copilot 读取上下文的时候能看到，就够了。
这一步不需要任何特殊权限，零成本。就跟在你家门口贴个小广告似的，你出门就能看见。
4.2 第二步：Copilot 中招
Copilot 读完上下文，根据「用户的意图」开始生成代码。
由于 prompt injection 的设计，Copilot 会觉得：哦，用户想往 settings.json. 这个路径写配置对吧？行，我帮你生成。
这时候安全检查启动了，看了一眼路径------settings.json.，带个点尾巴，不在保护列表里。放行。
Copilot 开开心心地调用文件系统 API，开始写入。
4.3 第三步：路径截断
Windows 内核拿到路径一看：哟，末尾有个点，老规矩，截了。
于是 settings.json. 变成了 settings.json。
恶意配置内容，就这么堂而皇之地写进了受保护的配置文件里。
整个过程，Copilot 全程蒙在鼓里。它以为自己写的是一个无关紧要的文件，实际上把人家的保险箱给撬了。
4.4 第四步：命令执行
settings.json 被改了之后会怎么样？
这个文件里可以定义 task，可以配置 extension，可以指定 MCP server 的端点。
换句话说，攻击者想让它执行什么命令，它就执行什么命令。
下一次 Copilot 启动的时候，读取被篡改的配置，恶意代码就跑起来了。
远程代码执行，达成。
你看整个链路------没有复杂的 exploit 技巧，没有内存破坏，没有堆溢出，没有信息泄露的铺垫。就是一个句点，加上两层系统的理解不一致。
5. 影响范围和修复情况
5.1 谁中招了
受影响的版本，包括 Visual Studio 2022 和 SSMS 的相关版本。
微软官方把这个漏洞的严重性定为 Important（重要），而不是 Critical（严重）。
但 CVSS 评分是 8.8。
有人可能会问：这两个定级是不是矛盾？
微软的逻辑大概是：这个漏洞需要用户交互才能触发------你得打开一个被污染的项目，Copilot 才会中招。不是那种远程打个包就能直接 RCE 的类型。
但问题是------当一个「需要用户交互」的漏洞，可以通过污染 GitHub PR 描述来远程触发的时候，这个定级是不是保守了点？
你想想，开发者每天要 review 多少 PR？要看多少 issue？这些地方全是攻击面。
5.2 修复了什么
微软的修复方向很直接：让安全检查层的路径标准化逻辑，跟 Windows 内核层保持一致。
具体怎么做？安全检查在判断路径是否在受保护列表里之前，先调用跟操作系统相同的规范化函数。
确保路径字符串跟实际文件路径一致了，再做匹配。
说白了就是：以前是检查站自己瞎猜这个路径是啥，现在改成问内核了------你告诉我这个路径最终会落到哪？
方向是对的。但这个坑，从 DOS 时代埋到现在，几十年了才被 AI 工具给踩出来。
5.3 赏金是多少
说个有意思的细节。
Rehberger 是 2026 年 8 月 4 日向微软报告的这个问题。8 月 30 日跟进确认。9 月 16 日微软正式承认漏洞存在。10 月 13 日 Patch Tuesday 发布修复补丁。
然后------漏洞赏金是 0 美元。
是的，你没看错。CVSS 8.8 的远程代码执行漏洞，微软给了 $0。
Rehberger 自己在公开文章里也没隐瞒这事，大大方方写出来了。
你品，你细品。一个句点绕了 Copilot 的安全机制，值多少钱？在微软眼里，不值钱。
6. AI 工具的安全边界问题
6.1 新的攻击面
这个漏洞暴露的问题，远不止 Copilot 一个产品。
传统的软件安全模型是什么样的？攻击者主动输入恶意 payload，触发特定的代码路径。你做输入验证，做输出编码，做沙箱隔离，就能挡住大部分攻击。
但 agent 化的 AI 工具不一样了。
攻击者不需要直接触发漏洞。他只需要在 agent 能看到的上下文里，埋一条看似无害的指令。然后 agent 自己「理解」了这条指令，自己「决定」去执行，自己就把坑给挖好了。
你的 PR 描述，你的 issue 评论，你的代码注释------全都是攻击向量。
安全边界从「输入验证」扩展到了「上下文信任」。这是一个全新的命题。
6.2 开发者该怎么加固
从防御角度看，至少要做三层加固。
第一层，安全检查不能只看路径字符串，必须通过实际文件系统 API 查询最终路径。你觉得路径是 A，不算数，操作系统说路径是啥才是啥。
第二层，AI agent 工具要做沙箱隔离。它不能直接动生产环境的配置文件，尤其是那些被严格保护的系统级配置。
第三层，对 agent 的写入行为建立审计日志。每次写入，都记录实际目标路径，而不是请求路径。发现异常就阻断。
这三层做下来，就算某一层被绕过去了，影响范围也能控制住。
7. 最后说几句
Windows 用了几十年的兼容性特性，反而成了 AI 工具安全检查的盲区。
这事最值得记录的，不是漏洞本身，而是它背后的教训------当你在一个已经运行了几十年的系统上叠加新的智能层时，你以为的「常识」，在新的上下文里可能就是致命的假设。
安全检查层假设路径字符串等于文件系统实际操作的目标路径。这个假设在传统应用里没问题，因为应用开发者都知道 Windows 会截断点号。但 AI 不知道。AI 是在训练数据里学会「路径长这样」的，它没学过 Windows 内核的那些祖传兼容性包袱。
于是就出事了。
问题出在一个句点上。但根子，在两个世界的理解鸿沟里。
目前能做的动作也很简单：赶紧升级 Visual Studio 和 SSMS 到最新版本；检查一下你项目里的 AI agent 工具，有没有对配置文件的写入权限；看看有没有类似的路径截断绕过风险。
别等被人挖了才想起补。一个句点的事，不值得你熬夜加班。
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01