作者：Swati Khandelwal
发布日期：2026 年 7 月 9 日
信息来源：The Hacker News
Wiz 的研究人员发现，六款流行的 AI 编程助手存在一类缺陷：经过恶意设计的代码项目可能在开发者毫不知情的情况下控制其计算机。助手请求用户批准编辑一个看似无害的文件，实际写入的却是另一个敏感文件。
受影响的工具包括 Amazon Q Developer、Anthropic Claude Code、Augment、Cursor、Google Antigravity 和 Windsurf。Wiz 将这一漏洞模式命名为 GhostApproval，并于 7 月 8 日公开研究结果。
在这六款工具中，三款已经发布修复，两款尚未修复，Anthropic 则不认同将这一行为定性为漏洞。风险最高的是那些在用户作出决定之前就已修改文件的工具。
攻击如何发生
这类攻击利用了一个由来已久的 Unix 功能——符号链接（symbolic link，简称 symlink），而这些编程助手没有对它进行充分检查。符号链接会悄然指向磁盘上的另一个文件，因此，对链接执行的写入操作最终会落到它指向的目标文件中。
Wiz 构造了一个恶意仓库，其中包含名为 project_settings.json 的符号链接，但它实际指向受害者用于 SSH 登录认证的 ~/.ssh/authorized_keys。仓库里的 README 指示助手向 project_settings.json 添加“一行设置”；这行看似无害的设置，实际上是攻击者自己的 SSH 公钥。
只要让智能体“配置工作区”或“按照 README 操作”，它就可能顺着符号链接，将攻击者的公钥直接写进 SSH 登录文件。如果这台机器运行着攻击者能够访问的 SSH 服务，对方随后便可在无需密码的情况下登录。
另一种攻击方式会把内容写入 ~/.zshrc。每当用户下次打开终端时，Shell 都会执行这个启动文件，因此攻击不再依赖 SSH。目前没有迹象表明这些手法已经用于真实攻击；Wiz 将其作为安全研究发布。
审批框显示的并不是真实目标
利用符号链接发动攻击并不新鲜。在 GhostApproval 中，符号链接只是投递手段，真正失效的是审批框：它向用户展示了错误的信息。
Wiz 在测试 Claude Code 时发现，智能体在自身推理过程中其实已经识别出了真实目标，并指出 project_settings.json“实际上是一个 zsh 配置文件”。然而，开发者最终看到的审批框里，只显示了那个无害的文件名。
用户以为自己批准的是修改本地配置文件，点击“接受”后，写入操作却落到了 Shell 启动文件或 SSH 密钥文件上。Wiz 将其称为知情同意绕过：人类看似仍在决策闭环中，但系统向其展示的并非事实。
有些工具的表现更加危险：它们完全跳过审批环节，让用户没有任何干预机会。Windsurf 会在“接受”和“拒绝”按钮出现之前就把内容写入磁盘，因此这个提示实际上只是一个撤销按钮；等用户看到它时，恶意密钥已经写入目标文件。
Augment 甚至不会显示对话框。Wiz 演示了它如何在无提示的情况下读取项目目录之外的 AWS 凭证文件。那些仍会弹出提示的工具也不能因此被视为安全，因为提示框显示的依旧是错误的文件。
哪些工具受到影响
Wiz 已将问题报告给全部六家厂商。截至文章发布时，各款工具的处理状态如下：
| 工具 | 状态 | 应对措施 |
|---|---|---|
| Amazon Q Developer | 已在 Language Server 1.69.0 中修复（CVE-2026-12958） |
及时更新。多数用户会自动安装，重新加载 IDE 即可获取更新。 |
| Cursor | 已在 v3.0 中修复（CVE-2026-50549） |
从扩展管理器更新。 |
| Google Antigravity | 已修复，CVE 尚待公布 | 更新至当前版本。 |
| Augment | 已确认问题，尚未修复 | 不要让它处理不受信任的仓库。 |
| Windsurf | 已确认问题，尚未修复 | 不要让它处理不受信任的仓库。 |
| Anthropic Claude Code | 不认同漏洞定性；当前版本会发出警告 | 更新至当前版本，并在批准前仔细阅读符号链接警告。 |
Anthropic 对这一漏洞定性提出异议。该公司告诉 Wiz，这种情况“超出了我们的威胁模型”：开发者在启动会话时主动选择信任该文件夹，之后又批准了文件编辑，因此这项决定应由开发者负责。
Anthropic 还表示，Claude Code 的符号链接警告早在 2 月初便已上线，时间早于 Wiz 的私下报告；这属于常规安全加固，并非针对该报告的修复。Anthropic 先前发出的“不予置评”回复则是自动生成的。
在六家厂商中，Anthropic 是唯一明确表示这不是漏洞的一方；另有三家已发布修复，两家正在处理。不过，Anthropic 的立场提出了一个真实存在、也并非只有它需要回答的问题：当开发者已经选择信任一个恶意仓库时，编程智能体究竟应该在多大程度上继续保护开发者？
无论使用哪款工具，除了及时安装补丁之外，以下习惯也能降低风险：
• 限制智能体能够访问的文件范围，或让它在沙箱、容器中运行。
• 在允许智能体“配置”仓库之前，先检查仓库的 README 和隐藏配置文件。
• 处理完陌生仓库后，检查项目目录之外的重点目标，包括 Shell 启动文件、SSH 密钥以及 AI 工具自身的配置文件。由于这些文件位于仓库之外，它们的变化不会出现在 git status 中。
例如，可以通过 ls -la ~/.zshrc ~/.ssh/authorized_keys 查看文件时间戳，确认它们是否在智能体运行期间发生过变化。
Wiz 给工具开发者的建议很直接：在请求用户批准之前，先解析符号链接并展示真实目标；凡是写入项目目录之外的操作都应明确警告；而且，在用户真正批准之前，绝不能触碰磁盘。
这是整个行业的共同缺陷，而非单一厂商的疏漏
今年 5 月，Adversa AI 发布了 SymJack 研究，针对包括 Claude Code、Cursor、GitHub Copilot 和 Grok Build 在内的六款编程智能体，披露了同样的“符号链接加欺骗性审批”攻击模式。
两个独立团队先后发现同一问题，说明这是一种共有的设计弱点，而非某家厂商的偶然失误：这些智能体使用普通文件操作跟随符号链接，却根据最初收到的路径请求审批，而不是根据写入最终落到的真实路径进行审批。
两项研究甚至在 CVE 层面发生了交集。Cursor 在其符号链接漏洞公告中，同时致谢了 Wiz 和 Cato AI Labs；The Hacker News 此前曾以 DuneSlide 为题报道 Cato AI Labs 的研究。
AI 助手所信任的文件，已经不再只是代码。对这些智能体而言，这些文件还会充当它们遵循的指令、操作的路径，并影响审批框向用户展示的内容。AWS 的公告还涉及 Amazon Q 的另一个漏洞 CVE-2026-12957：一旦用户信任工作区，经过投毒的仓库就可能自动加载配置文件并执行命令，窃取开发者的 AWS 密钥。
GhostApproval 的具体攻击方式目前仍停留在研究阶段，但更广泛的恶意模式已经出现在真实世界中：攻击者把能够引导 AI 智能体执行不安全操作的文件放进代码仓库。
正如 The Hacker News 在 6 月报道的那样，Miasma 蠕虫曾将 AI 智能体配置文件植入 Microsoft Azure 仓库，使开发者一旦在 Claude Code、Cursor 或 Gemini 中打开项目，就会执行其载荷。GitHub 随后禁用了受到影响的 73 个 Microsoft 仓库。
只有当系统向人类如实展示情况时，“人在回路”才能真正发挥保护作用。随着编程助手获得越来越大的自主文件读写权限，一个显示错误目标的审批框不仅无法充当安全保障，反而会成为风险来源。若把恶意仓库造成的欺骗完全归咎于用户，等于把责任推给了最难看清路径偷换的人。
