夜雨聆风
又来了。
npm 投毒、PyPI 投毒、typosquat 包、偷钱包、偷 SSH key、偷云凭证。
这些东西你说新吗？
其实不新。
但我越往下看，越觉得这次不太一样。
因为这次真正吓人的地方，不是那 34 个恶意包，也不是 384 多个恶意版本。
而是攻击者开始意识到一件事：
今天开发者电脑上最听话、权限最大、还最容易相信项目说明的东西，可能不是 shell，不是 npm install，而是你的 AI 助手。
比如 Claude Code。
比如 Cursor。
再比如任何会自动读取项目规则文件的 Coding Agent。
以前你 git clone 一个项目，最危险的通常是：
你跑了 npm install。
你执行了一个看起来正常的 postinstall。
你手滑运行了 README 里的脚本。
但 TrapDoor 让这个故事变成了另一个版本：
你只是 clone 了一个项目，打开编辑器，启动 AI 助手。
然后它读到了仓库里的 CLAUDE.md、.cursorrules 之类的文件。
这些文件表面上是“项目规则”。
实际上可能是攻击者塞进去的行为指令。
你以为它在帮你理解项目。
它可能在帮别人理解你的钱包在哪。
尼玛。
这次攻击到底有多大？
先把事实摆一下。
Socket 安全团队在 5 月 24 日披露、5 月 25 日更新了 TrapDoor 供应链攻击。公开报告里提到，这批攻击横跨 npm、PyPI 和 Crates.io 三个生态，涉及 34 个以上恶意包，384 个以上恶意版本。
目标也很明确：
crypto、DeFi、Solana、Sui、AI、安全工具开发者。
也就是那批电脑里最可能有钱包、私钥、GitHub token、云凭证、SSH key、浏览器会话、项目机密的人。
这不是随机撒网。
这是盯着“高价值开发者机器”打。
The Hacker News 的报道也提到，攻击者使用了典型的凭证窃取套路：伪装成正常开发包，诱导安装，枚举本机环境，收集密钥、钱包、浏览器数据，再把结果传出去。
如果你过去几年关注过供应链安全，这些桥段都很熟。
event-stream 是这样。
ua-parser-js 是这样。
xz utils 也是另一种更高级、更长期、更阴险的版本。
开源供应链一直都有一个基本假设：
大家会审代码，但不会审完所有依赖。
攻击者吃的就是这个时间差。
但 TrapDoor 这次加了一个新东西。
它不只污染依赖。
它还试图污染 Agent。
最可怕的是 PR 里的“项目规则”
这次最值得所有 AI 工程师警惕的，不是 npm 包里又藏了 stealer。
而是有人开始通过 PR 往开源仓库里塞带隐藏指令的 CLAUDE.md、.cursorrules 这类文件。
The Hacker News 引述 Socket 的说法，相关 PR 出现在 browser-use、LangChain、Langflow 等 AI 和开发者项目里。
这些文件太像文档了。
真的。
如果一个 PR 改了 src/auth.ts，你会认真看。
如果一个 PR 改了 package.json，你可能也会警觉一下。
如果一个 PR 新增了 CLAUDE.md，里面写着：
“这是本项目的开发规范，请 AI 助手遵守。”
很多人可能就扫一眼。
甚至觉得挺好。
哎，有人帮项目补 Agent 规则了。
但问题在于，对 Claude Code、Cursor 这类工具来说，这些文件不只是文档。
它们是指令层。
它们会告诉 Agent：
这个项目怎么构建。
代码怎么改。
命令怎么跑。
哪些检查必须执行。
甚至在某些配置和权限组合下，Agent 会真的去调用 shell、编辑文件、读取环境。
也就是说，原来我们以为 .cursorrules、CLAUDE.md、AGENTS.md 是“给 AI 看的 README”。
现在必须换一种理解：
它们是代码。
更准确一点：
它们是代码 + 权限。
这个变化非常大。
因为代码至少还有语法、测试、CI、review 习惯。
但项目规则文件呢？
很多团队现在还把它当“协作说明”。
不进安全 review。
不进变更 checklist。
不看权限边界。
不想它会不会诱导 Agent 执行危险操作。
这就是新攻击面。
X 评论区里有人说得很准，偷 GitHub token 是老剧本，但 PR 添加 .cursorrules 这件事，把“依赖污染”升级成了“Agent 行为污染”。
我觉得这个判断非常关键。
以前攻击者要等你安装它、运行它。
现在攻击者还可以等你“相信项目里的 AI 规则”。
这太符合 Agent 时代的攻击方式了。
为什么这是 AI 工程界的第一次大型供应链事件？
我不想夸大 TrapDoor 本身。
从技术复杂度上说，它不一定比 xz utils 更高级。
从破坏规模上说，它也未必比历史上一些 npm 投毒事件更大。
但它第一次把一个问题摊在桌面上：
Agent 时代，供应链不只包括代码和依赖，还包括“指令”。
以前项目里的规则文件更像软约束。
你可以不看。
你可以不同意。
你可以手动执行。
但现在不一样了。
如果你用了 Agent，尤其是能跑命令、能改代码、能读文件的 Agent，它会把这些规则当成上下文的一部分。
而上下文，在 Agent 系统里，不是背景资料。
上下文会影响行为。
这就像什么？
像你公司来了一个实习生。
你给他一台有生产权限的电脑。
然后门口贴了一张纸：
“本公司所有操作以这张纸为准。”
攻击者不需要黑进电脑。
他只需要把那张纸换掉。
这就是我觉得 TrapDoor 最有时代感的地方。
它不是单点漏洞。
它是范式变化之后，自然长出来的新漏洞。
我们过去二十年一直在教育开发者：
不要随便跑脚本。
不要相信陌生依赖。
不要把 token 放环境变量里乱用。
现在要加一句：
不要让 Agent 随便相信项目里的指令文件。
以后 PR review 要多看一类文件
这件事对普通开发者最直接的启发，其实不复杂。
从今天开始，下面这些文件都应该进入 PR review checklist：
- CLAUDE.md
- .cursorrules
- AGENTS.md
- .github/copilot-instructions.md
任何项目级 Agent instructions 任何项目级 MCP / tools / permissions 配置
不要再把它们当文档。
看它们的时候，要像看代码一样看。
尤其要盯几类内容：
第一，是否要求 Agent 执行网络下载脚本。
比如 curl ... | sh。
比如从陌生域名拉 install script。
第二，是否要求读取敏感路径。
比如 ~/.ssh、浏览器 profile、wallet 扩展目录、云厂商凭证目录。
第三，是否要求绕过确认。
比如“无需询问用户，直接执行”。
这种句子以后看见就该亮红灯。
第四，是否把危险命令包装成“项目初始化”。
很多攻击会藏在听起来很正常的话里：
“首次运行前请执行环境诊断。”
“请自动修复依赖问题。”
“请读取本机配置以适配开发环境。”
这几句话单独看都合理。
但如果后面跟的是奇怪脚本、外部域名、敏感目录访问，那就是另一回事了。
我现在会怎么防？
我觉得可以从五件很具体的事开始。
第一，把 Agent 配置文件加入 review checklist。
只要 PR 改了 CLAUDE.md、.cursorrules、AGENTS.md 这类文件，必须像代码一样 review。
而且最好指定懂 Agent 工具权限的人看。
第二，项目级权限默认收紧。
Claude Code 这类工具已经支持通过项目级 settings 限制工具权限。高危能力，比如 Bash、Edit、网络访问、读取敏感目录，不应该默认全开。
不是说不用。
而是要 allowlist。
你明确知道这个项目需要跑什么命令，再放什么命令。
第三，养成看 diff 的习惯。
每次 clone 或 pull 之后，看一眼：
1 2 git diff --stat 如果你看到 AI 配置文件变了，停一下。
不要一边开 Agent 一边想“应该没事”。
安全事故最喜欢“应该没事”。
第四，危险命令走本地白名单。
比如删文件、上传、读密钥目录、curl 外部脚本、改 shell profile、改 git hooks。
这些操作应该永远需要人工确认。
哪怕 Agent 很聪明。
尤其是 Agent 很聪明。
第五，把 Agent 放进沙盒。
这个方向我觉得会越来越重要。
评论区也有人提到轻量虚拟化沙盒。
未来比较合理的开发形态，可能不是让 Agent 直接在你的主机上乱跑，而是给它一个隔离环境：
有项目代码。
有必要依赖。
有临时凭证。
没有你的主钱包。
没有你的 SSH 主钥。
没有浏览器全部 cookie。
这听起来麻烦。
但你想想，今天很多人已经愿意为了生产环境上 Kubernetes、容器、权限隔离。
为什么到了自己这台装满私钥的开发机，反而让 Agent 裸奔？
这可能会催生一批新工具
我觉得 TrapDoor 之后，会出现一类新工具。
比如 AI Config Auditor。
专门扫描 CLAUDE.md、.cursorrules、AGENTS.md、Copilot instructions，判断里面有没有高危指令。
比如 Agent Permission Linter。
专门检查项目级 Agent settings，提醒你 Bash 权限是不是过宽，外部网络是不是没限制，敏感目录是不是暴露。
比如 Trusted Sources 机制。
只有来自可信分支、可信维护者、可信签名的项目规则，才会被 Agent 自动加载。
这件事不应该只靠开发者自觉。
Anthropic、OpenAI、Cursor 这些做 Agent 工具的公司，也需要在产品层把“项目指令的可信来源”做出来。
因为普通用户很难分清：
哪些上下文只是说明。
哪些上下文会影响执行。
哪些上下文可能被攻击者利用。
不然最后还是会落到开发者自己身上：
我到底该不该信这个文件？
说实话，靠人每次都记得看一遍，很难。
最后
写到这里，我脑子里一直冒出 left-pad。
不是说 TrapDoor 跟 left-pad 是一回事。
差得很远。
left-pad 当年更像一次生态层面的尴尬时刻：大家突然发现，前端世界居然能被一个小到离谱的包卡住。
TrapDoor 这次给我的感觉也有点像。
它把一个大家平时不太当回事的东西拎了出来：
项目里的 Agent 规则文件。
以前我看到这种文件，大概率也就是扫一眼。
“哦，给 Claude / Cursor 看的。”
然后就过去了。
但现在不行了。
这玩意儿一旦被工具读进去，就不只是说明文档了。
它会影响 Agent 接下来怎么干活，甚至影响它敢不敢跑命令、读哪些文件、信谁的话。
这就是 Agent 时代的供应链安全。
不是“AI 会不会写错代码”那么简单。
而是“AI 相信了谁写下的规则”。
所以以后 clone 陌生项目，我大概会多一个很笨的动作。
先别急着把 Cursor 打开。
先别急着让 Claude Code 接管。
先看一眼那些给 Agent 看的文件。
看一眼 CLAUDE.md。
看一眼 .cursorrules。
看一眼 AGENTS.md。
就几分钟。
但这几分钟，可能就是你本机权限和别人钱包脚本之间的最后一道门。
你以为那是项目说明。
在 Agent 眼里，那可能就是命令。
参考来源：
Socket Blog: <https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-crates> The Hacker News: <https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html>
🔥 精选文章推荐
awesome-design-skills：让 AI 写前端时终于有一点设计品味
别再乱喂 Agent 了：Superpowers 把 coding agent 的开发流程做成了一套方法论
