微软Copilot安全机制被一个「句点」绕过了

一个句点引发的远程代码执行

微软安全研究员Johann Rehberger在X上发了一条配图的推文------代码看起来没问题，他问「这有什么毛病？

CVE-2026-103572的严重程度标注为「严重」，影响的是微软Visual Studio Copilot和SQL Server Management Studio（SSMS）。表面上看，是一个安全功能被绕过。深挖之后发现，问题的根源不在AI，而在Windows本身。

Windows路径解析的古老陷阱

这个坑埋了几十年

Windows在解析路径时会静默截断文件名末尾的点号。这是一个遗留自DOS时代的兼容性特性------旧版短文件名规范不允许以点号结尾，所以Windows内核层一直在做这件事，不需要应用层感知。

问题在于，系统文件层在写入文件时做了截断，而应用层在检查路径时没有做同样的处理。两层行为不一致，给了漏洞可乘之机。

具体来说，当Copilot尝试往C:\Users\xxx\.vscode\settings.json.写入配置时，安全检查会认为目标路径带有点号后缀，不是合法的配置文件路径，从而放行。但Windows真正执行写入时，点号被截断，最终落盘的路径就是settings.json------一个被严格保护的配置文件。

安全检查以为在写A，实际写的是B

更准确地说，这是CWE-94的一个经典变体：代码生成控制不当。只不过这里「生成代码」的媒介不是传统意义上的脚本，而是Copilot生成的settings.json内容，最终通过VSCode配置执行体系落地。

Copilot安全检查为何被绕过

两个系统的理解不一致

Copilot的安全机制对settings.json这类敏感文件有一个拦截规则：当Copilot检测到目标文件路径属于受保护配置时，会阻止写入操作。但这条规则的实现，依赖的是Copilot自身对路径字符串的判断，而不是调取Windows文件系统API做一次真实解析。

这意味着：安全检查看到的是settings.json.，认为它不在白名单内，于是放行。真正的写入操作由Windows完成，路径被截断后变成settings.json，落盘成功。

最危险的漏洞往往不是代码写错了，而是两个系统对同一件事的理解不一样。这里两个系统是：Copilot的安全检查层，和Windows的路径解析层。它们各自都「正确」，但它们对「同一个文件路径」的判断结果不同。

系统集成中最难的一类bug

这个问题本质上是一个跨层边界的一致性问题。安全检查层假设路径字符串等于文件系统实际操作的目标路径，但Windows内核层面的静默截断打破了这个假设。

从prompt injection到命令执行的完整链路

攻击链条并不复杂。攻击者通过一个精心构造的prompt，诱导Copilot在生成项目配置时，将恶意的settings.json内容写入一条看似无害的路径。

更准确地说，攻击者需要两步。第一步是利用LLM的输出内容，让Copilot生成一段包含特定路径的JSON配置，其中目标文件路径包含末尾点号。第二步是利用Windows的静默截断行为，让这个路径在实际写入时避开安全检查，直接覆盖settings.json。

一旦settings.json被修改，攻击者可以注入自定义的task定义或代码执行指令。在Visual Studio和SSMS中，settings.json被某些插件和执行框架读取，因此恶意配置会随后续操作被加载执行，实现远程代码执行。

``mermaid

CVE-2026-103572攻击链路

这段链路里没有复杂的exploit技巧，没有内存破坏，也没有零日漏洞。它的核心就是：Windows的行为一致性，被Copilot的假设打破。

影响范围与修复现状

受影响的版本包括Visual Studio 2022及SSMS的相关版本，具体以微软2026年10月Patch Tuesday发布的更新为准。微软将此事评级为「重要」（Important），但CVSS评分为8.8，说明其实际危害程度已经接近高危。

根据Rehberger在X上的披露时间线，他在2026年8月4日向微软报告了路径绕过问题，8月30日跟进确认，微软于9月16日正式确认漏洞存在，最终在10月13日的Patch Tuesday中发布修复补丁。微软给出了$0的赏金------这一点Rehberger自己在文章中也没有隐瞒。

漏洞的修复方向是将安全检查层的路径标准化逻辑与Windows内核层保持一致。具体实现是：安全检查在判断路径是否在受保护列表中之前，先调用与操作系统相同的规范化函数，确保路径字符串与实际文件路径一致后再做匹配。

Windows用了几十年的兼容性特性，反而成了AI工具安全检查的盲区。这个教训比修复本身更值得记录。

问题出在一个句点上。

Windows路径解析的古老陷阱

Windows的尾部点号截断不是新特性，而是从DOS时代延续下来的兼容性包袱。在早期文件系统中，文件名不能以点号结尾------这会导致与短文件名表示产生歧义。因此Windows内核在打开或创建文件时，会静默去掉末尾的所有点号。这一行为对所有应用程序透明，意味着无论你是用CreateFile、_wfopen还是.NET的File.Open，结果都一样。

但Copilot的安全检查发生在更高层------它在调用文件系统API之前，先对用户请求的路径做了一次白名单校验。检查逻辑只看到了"settings.json."，而这个路径不在被允许写入的配置文件中。于是检查通过，调用落地，Windows自动截断了点号，最终写入的是受保护的"settings.json"。

安全检查站在用户请求的层面，文件系统站在内核层面，中间缺少了一次「实际写入路径还原」的环节。

Copilot安全检查路径 vs 文件系统实际路径

Copilot安全检查为何被绕过

从 CWE 分类来看，CVE-2026-103572属于 CWE-94（代码注入），但更准确地说，这是一个路径规范化缺失导致的安全特性绕过。Copilot 的内置安全检查有一个白名单机制------它允许写入用户项目目录下的配置文件，但明确禁止写入受保护的 settings.json 等系统级配置文件。

这个白名单的逻辑是：检查用户请求的目标路径字符串是否匹配白名单条目。问题在于，检查时用的字符串是用户请求的原始字符串，而文件系统实际写入的路径是经过 Windows 处理后得到的结果。两者之间存在一个"语义鸿沟"------Copilot 认为自己在阻止用户写入受保护路径，但 Windows 帮用户改写了路径，让检查失效。

微软研究员 Johann Rehberger 在发现这个问题后，通过精心构造的 prompt injection 完成了整个攻击链：诱导 Copilot 认为写入操作是安全的，触发路径截断，最终实现任意配置写入。

从 prompt injection 到命令执行的完整链路

攻击链的每一步都不复杂，组合起来却致命：

第一步，攻击者在用户可见的上下文（如 PR 描述、issue 评论、或嵌入的代码注释）中植入恶意 prompt。这一步不需要任何特殊权限，只要用户查看被污染的内容即可触发。

第二步，Copilot 读取上下文后，根据用户的编码意图生成写入配置的 suggestion。由于 prompt injection 的设计，Copilot 会认为这是一个合法的操作请求。此时安全检查看到的路径是带有尾部点号的版本，白名单校验通过。

第三步，Copilot 调用文件系统 API 写入文件。Windows 截断点号后，实际写入的是受保护路径。恶意配置内容被持久化到 settings.json。

第四步，后续 Copilot 或相关工具读取这个被篡改的配置，触发命令执行。具体执行什么命令取决于攻击者写入的内容------可以是 MCP server 指向恶意端点，可以是 extension 配置指向恶意插件，也可以是任何被 Copilot 读取并执行的配置项。

完整攻击链

影响范围与修复现状

该漏洞影响 Visual Studio Copilot 和 SQL Server Management Studio（SSMS）。微软将其严重性定为 Important（而非 Critical），CVSS 评分 8.8。这个定级可能反映了微软认为需要用户交互这一限制条件，但从攻击链来看，一旦 prompt injection 成功，用户只需正常使用工具就会触发。

微软已在 2026 年 10 月的 Patch Tuesday 更新中发布修复。Johann Rehberger 于 2026 年 8 月向微软报告，10 月 11 日获得 $0 漏洞赏金，10 月 13 日公开了技术细节和 PoC。

AI辅助工具的安全边界问题

CVE-2026-103572 揭示的问题不局限于 Copilot 这一个产品。它的本质是：当一个 agent 获得了文件写入权限，安全检查应该覆盖 agent 的实际行为结果，而不仅仅是它的输入意图。

更广泛地说，AI 辅助工具的安全边界正在被重新定义。传统的软件安全模型假设攻击者需要主动利用漏洞------输入恶意 payload、触发特定的代码路径。但 agent 化工具引入了一个新的攻击面：攻击者不需要直接触发漏洞，只需要在 agent 可见的上下文中埋入一条看似无害的指令，让 agent 自己"理解"并"执行"恶意操作。

这意味着安全边界从"输入验证"扩展到了"上下文信任"。你的 PR 描述、issue 评论、甚至是代码注释中的文本，都可能成为攻击向量------只要 agent 能看到它并据此采取行动。

从防御角度看，开发者需要在三个层面加固：第一，安全检查应通过实际文件系统 API 查询最终路径，而非仅验证用户请求的字符串；第二，AI agent 工具应沙箱隔离，限制其对生产环境配置文件的访问；第三，对 agent 的写入行为建立审计日志，发现异常即阻断。

微软将 Copilot 的安全定级为 Important 而非 Critical，这个判断值得推敲。CVSS 8.8 的分值说明影响确实严重，但 Important 可能暗示微软认为需要特定条件才能利用。实话说，当一个"需要用户交互"的漏洞可以通过污染 GitHub PR 描述来远程触发时，这个定级是否保守了？

目前可执行的动作是：立即升级受影响的 Visual Studio 和 SSMS 版本；审查项目中是否有 AI agent 工具对配置文件的写入行为，评估是否存在类似的路径截断绕过风险；建立 agent 工具的写入审计机制，记录每次写入的实际目标路径而非请求路径。

参考文献

延伸入口

原文归档：tobemagic.github.io/ai-magician...
公众号：计算机魔术师