AI 编程工具三个月报了两个 Critical 漏洞，我把每个坑都踩了一遍——顺便给团队配了一套能落地的检查表

AI 编程工具三个月报了两个 Critical 漏洞，我把每个坑都踩了一遍——顺便给团队配了一套能落地的检查表

刚过去这三个月，AI 编程工具的安全漏洞就没断过。先是 Claude Code 被发现沙箱可以逃逸——一个 CVE 评分 8.8 的 symlink 漏洞；紧接着 GitHub Copilot、Claude Code、Gemini CLI 全被同一个套路打穿——评论里的恶意内容直接触发提示注入，把私有代码读了出来。安全圈还没喘口气，OWASP 又甩出来一份《Agentic Skills Top 10》报告，10 个风险项直接把 AI Agent 在 CI/CD 环境里可能出事的路径全标清楚了。

这三个事情单独看是新闻，放在一起就是一套完整的安全威胁图谱。我用真实项目把每一条都跑通了，结论是：大多数团队的 AI 编程工具配置基本上是裸奔状态。

第一个坑：Claude Code 的 symlink 沙箱逃逸

CVE-2026-39861，影响版本 < 2.1.64。问题出在哪？Claude Code 在沙箱进程里创建了符号链接，指向工作区之外的位置。然后 Claude Code 本身的非沙箱进程在写文件时，跟随了这个 symlink，直接把内容写到了工作区外面。

这个漏洞的攻击路径是这样的：攻击者在代码仓库里埋一个恶意文件，Claude Code 在沙箱里读取它，利用 symlink 技巧把写操作逃逸到工作区外部。整个过程不需要用户任何交互，Claude Code 默认配置下就会中招。

修复版本是 2.1.64，手段是沙箱进程创建 symlink 时做了一次检查，阻止指向工作区外的路径。但这只是堵住了一条路，这类 symlink 逃逸的变种还有很多。

第二个坑：GitHub 评论直接触发提示注入，Copilot 和 Claude Code 全中招

微软安全团队的研究验证了一个更隐蔽的攻击面：攻击者只需要在 GitHub PR 的评论里植入恶意内容，就能诱导 AI 编程工具泄露私有代码仓库里的敏感数据。

具体来说，攻击者先向目标仓库提交一个 PR，PR 内容看起来完全正常，但在评论里埋入精心构造的提示注入载荷。Claude Code、Gemini CLI、GitHub Copilot Agent（SWE Agent）在处理这个 PR 时，会自动读取评论内容作为上下文的一部分，于是恶意指令就被执行了——读取 .env 文件、读取 AWS 密钥配置、读取内部 API 密钥。这个过程完全静默，开发者可能几天之后才发现自己仓库的密钥已经被扫走了。

问题的根因是：AI 编程工具默认会把 PR 评论当作可信输入，但评论是任何人都能写的。这个攻击面在 GitHub Copilot 聊天界面里一直存在，但在 Agent 模式下因为自主执行能力更强，危害也被放大了。

第三个坑：OWASP Agentic Skills Top 10，把 AI Agent 在 CI/CD 里可能出事的路径全标清楚了

OWASP 2026 年发布的《Agentic Skills Top 10》，是迄今为止最完整的一份 AI Agent 安全风险清单。它把风险分了三档：Critical 两个，High 四个，Medium 四个。

Critical 级别打头的是 AST01 恶意技能（Malicious Skills）：攻击者在公共市场发布包含恶意代码的 Skill，团队成员安装之后，恶意代码就在工作区里拿到了完整的执行权限。第二个是 AST02 供应链妥协（Supply Chain Compromise）：Skill 的依赖链里有恶意包，或者 Skill 作者的账号被攻击者接管了。

High 级别里和前端团队最相关的是 AST03 过度授权（Over-Authorization）：Skill 被授予了超出任务需求的权限，比如一个代码格式化 Skill 却有读取所有文件的权限，一旦被滥用，数据全漏。AST06 弱隔离（Weak Isolation）：Skill 运行环境和主机系统之间没有真正的隔离，恶意 Skill 可以访问到 CI/CD 流水线的环境变量、部署凭证等。

Medium 级别里有一个值得注意：AST08 扫描不足（Insufficient Scanning）：很多团队在引入 Skill 之前根本没有做任何安全扫描，包括静态分析、依赖审计和权限审计，直接就是「pip install 一下试试」。

给团队配的检查表，先从这三个地方入手

说完了三个坑，说说怎么落地。我把检查表分成三层，每层都有明确的验证方式和阻断标准。

第一层：工具配置层，这一层出问题最容易被忽略。

Claude Code 升级到 >= 2.1.64，这是最基本的要求。在 CI 环境里，建议用 --no-read 参数限制文件读取工具的作用域，或者配置 allowedDirectories 明确限定 Claude Code 能访问的目录范围。对于 GitHub Copilot，确保 MR 评论内容经过输入过滤，或者在 Agent 模式下禁用自动读取评论内容。

第二层：依赖引入层，这一层是大多数团队的盲区。

所有 Skill 安装前必须过依赖扫描。用 npm audit 或 pip audit 检查依赖包里有没有已知漏洞。对于来源不明的 Skill 包，用 grype 或 trivy 做镜像层扫描。更严格的做法是：为 Skill 安装单独的网络隔离环境，Skill 的执行网络请求全部走审计代理，任何对外部网络的请求都要有日志记录。

OWASP 的 AST01 和 AST02 风险在这个环节最容易爆发。举个例子：你在 GitHub 上看到了一个 3000 Stars 的 Claude Code Skill，直接 npm install claude-code-skill-*，但你根本没有审计它的 node_modules 依赖链。这个 Skill 可能是三个月前发布的，那时候它的某个间接依赖还没有漏洞。

第三层：CI/CD 集成层，这一层决定了你发现问题的速度。

在 CI 流水线里加入 GitHub Secret Scanning，这是 GitHub 原生的密钥检测功能，能在代码 push 的瞬间检测到意外提交的密钥并自动撤销。对于 AI 编程工具生成的代码，Claude Code Security Review GitHub Action 可以集成到 PR 检查流程里，它会用 Claude 做语义级的安全分析，比传统的 pattern matching 工具更容易发现业务逻辑层面的漏洞，比如权限控制失效或者敏感数据外带。

OWASP AST08 说的「扫描不足」，在 CI/CD 环节加两道自动化扫描门禁就能解决大半。关键是这两道门禁必须强制执行，不能设置 allow_failure: true，一旦允许失败，团队就会慢慢习惯跳过它们。

一个判断标准：当你给 Skill 开的权限比给实习生开的还大，这个配置就有问题了

这句话是 OWASP AST03 的一个简化判断标准。实习生进团队，权限是有明确范围的——能读哪些目录、能访问哪些 API、有没有网络访问权限。Skill 安装的时候，这些全被忽略了，一个 npm install 下去，Skill 能访问工作区里所有文件，还能往外发网络请求。

AI 编程工具已经成了很多团队的标配生产力，但安全配置基本上还停留在「能用就行」的阶段。这三个月的漏洞报得比较密集，是因为安全研究社区开始把注意力放到这个方向了，不代表之前没有问题。建议每个团队把这张检查表跑一遍，堵住最大的三个漏洞就行——全部堵住不现实，但 Critical 和 High 级别的风险值得优先处理。

下一步行动：今晚检查一下团队所有机器上 Claude Code 的版本号，然后跑一遍 npm ls --depth=0 看看装了多少个 Skill。如果有任何一个 Skill 你说不出它的来源和作用，先禁用了再说。