夜雨聆风关注公众号，追踪科技热点
你克隆了一个 GitHub 仓库，让 AI 助手「配置一下工作区」。它弹窗问你「是否编辑 project_settings.json」，你点了接受。操作系统却顺着一条符号链接，把攻击者的 SSH 公钥写进了你的 ~/.ssh/authorized_keys。而那个对话框，从头到尾只字未提真实路径。
7 月 8 日，安全公司 Wiz 甩出一份报告，名字叫 GhostApproval。一句话概括：市面上六款主流 AI 编程助手，全部中招。你大概率正用着其中至少一个。
这份名单是 Amazon Q Developer、Anthropic 的 Claude Code、Augment、Cursor、Google Antigravity，还有 Windsurf（它后来改名叫 Devin Desktop）。攻击者不需要零日漏洞，不需要高级入侵，只要 Unix 系统里最普通的一个东西——符号链接（symlink）。
背景：发生了什么
先把时间线拉直：
• 今年 2 月 — Anthropic 在 Claude Code 里加了一条 symlink 警告横幅（这是后话，先记一笔）。
• 5 月 22 日 — Google 在公开披露前悄悄修掉了 Antigravity 的同类缺陷。
• 7 月 8 日 — Wiz 公开 GhostApproval，点名六款工具，披露攻击链完整细节。
• 同日 — Amazon、Cursor 已发补丁（带 CVE）；Google 也已修；Augment 和 Windsurf 确认收到报告，但到披露日还没修；Anthropic 直接争议了漏洞定性。
攻击本身一点都不花哨，就三步：
• 攻击者在仓库里放一个符号链接，名字叫 project_settings.json，看着人畜无害，但它实际指向 ~/.ssh/authorized_keys。
• 你克隆仓库，用 AI 助手打开，README 让你「配置一下工作区」。助手照做，准备往那个「配置文件」写点东西。
• 弹窗出现，文件名显示 project_settings.json，你点接受。操作系统却跟随符号链接，把攻击者的 SSH 公钥写进了你的授权列表。机器若开放 SSH，攻击者随时能远程登录。全程无报错、无告警。
这只是第一招。还有更阴的变体：符号链接指向 ~/.zshrc，恶意代码被写进你的 Shell 启动文件——不需要 SSH，每次开终端都自动执行。
Wiz 给这套攻击定性为两个老毛病的叠加：一个是 CWE-61（符号链接跟随，写文件前没把路径解析到真实目标），另一个是 CWE-451（界面误导，确认框只显示链接名、不显示真实目的地）。前者是 Unix 时代的老问题，后者才是 AI 助手特有的新坑。
最让人后背发凉的细节在这儿：在 Claude Code 和 Augment 的测试里，AI 自己的内部推理链其实已经识别出了危险目标——它明明白白写著「project_settings.json 其实是个 zsh 配置文件」。但这句话从来没出现在你看到的确认框里。Wiz 研究员 Maor Dokhanian 的话一针见血：「当代理展示一种行为、却执行另一种行为时，用户的批准毫无意义。确认框从安全控制退化成了形式。」
Windsurf 更离谱：它先把文件写进磁盘，再弹确认框。那个「接受/拒绝」按钮出现时，攻击者的 SSH 密钥早就进你的 authorized_keys 了。这哪是授权闸门，分明是事后撤销按钮。Augment 则是另一种极端——读写全静默，连确认框都没有，甚至能顺着符号链接读出工作区外的 AWS 凭证，直接把密钥明文吐在聊天里。
从几个角度看这件事
角度一 · 站在普通开发者
你什么都没做错。克隆仓库、按 README 操作、点了个看起来无害的「接受」——这是 2026 年最普通的开发动作。结果你批准的根本不是「本地编辑」，而是给攻击者发了一张你机器的永久门禁卡。你连「我中招了」都不知道。
角度二 · 站在企业安全
当一个开发者克隆陌生仓库、打开 IDE，就等于给整台机器开了个口子。这是供应链攻击的全新向量：不需要入侵你的服务器，只要污染一个开源仓库，你的研发机就自动「投敌」。而且 AI 助手权限越高，这个口子越大。
角度三 · 站在行业格局
六家厂商，三种态度。Amazon（CVE-2026-12958，High）、Cursor（CVE-2026-50549，Critical，v3.0 修）、Google（Critical，5/22 修）选了「当漏洞修」；Augment、Windsurf 到披露日还沉默；Anthropic 直接说「这不在我们的威胁模型里」——理由是开发者自己信任了这个文件夹、自己点了批准，决定权在开发者。可它 2 月加的那个警告横幅，是会话开始时闪一下的提示，不是审批那一刻告诉你「真实路径是 authorized_keys」。这两件事差了十万八千里。
角度四 · 站在「人在回路」本身
过去两年，所有 AI 编程工具的安全叙事都建立在一句话上：「反正有人类审批，不会乱来。」GhostApproval 把这句话的底裤扒了——当确认框显示的信息和真实操作对不上，审批就不是安全网，而是一张让人放松警惕的安慰毯。一个对低风险动作显示准确信息、对高风险动作显示错误信息的闸门，比没有闸门更危险，因为它制造了「我已经授权过了」的错觉。
再往下挖一层
根因一 · 「人在回路」的形式主义
这不是六个独立的 bug，是一类设计级缺陷。厂商把「有确认框」当成了「安全」的代名词，却忘了确认框的前提是信息对称。AI 看到了真实路径、人类没看到，那人类的「批准」就是个空壳。真正的安全，要么让人看到 AI 看到的一切，要么别让人为 AI 的决策背书。
根因二 · 能力与安全的结构性失衡
这些工具直接拿到了文件系统访问权 + 自主执行权，却把最后一道防线寄托在一个会「撒谎」的对话框上。Wiz 给的三条建议其实都不难：写盘前先解析符号链接、显示真实路径；路径在 workspace 之外就明确警告；授权前绝不写盘。难的不是实现，而是整个行业愿不愿意把这几条当成默认行为，而不是「可选加固」。
根因三 · 和前几篇是同一个母题
你如果一路跟我看到这儿，会发现一条暗线：grok-build 是厂商偷偷上传你的代码，Claude Code 后门是厂商在提示词里藏隐写标记，Claude 记忆漏洞是记忆被诱导外泄——那几篇是「厂商可能作恶」。GhostApproval 换了个维度：这次不需要 AI 公司有任何恶意，纯粹是设计缺陷被外部攻击者利用。你不需要信任 AI 公司，你只需要信任你克隆的那个 GitHub 仓库——而在开源世界里，这几乎没法完全避免。两个维度合在一起，才是完整的「AI Agent 安全威胁图」：能力总跑在治理前面，无论是主动越界还是被动留门。
最后说句实在的：如果你在用 AI 编程助手，克隆陌生仓库后、让 AI 动文件系统前，先检查里头有没有符号链接。这不是偏执，是 2026 年的基本开发素养。毕竟，你以为你点的是「接受」，攻击者点的是「登录」。
