你的 AI 编程助手,可能会读到攻击者写给它的命令

这几年，很多团队把 Claude Code、Cursor、Codex 这类工具当成了第二个开发者。

它们能读仓库、改代码、装依赖、跑脚本，也会认真遵守项目里的 CLAUDE.md、.cursorrules、AGENTS.md 之类的说明文件。这个设计本来是为了让 AI 更懂项目规范，但 AIHOT 2026-05-25 日报里提到的 TrapDoor 事件提醒我们：这些说明文件也可能变成攻击入口。

TrapDoor 不是普通的恶意依赖包。公开报道显示，它横跨 npm、PyPI、Crates.io 三个生态，涉及 34 个以上恶意包、384 个以上版本或产物，目标包括加密、DeFi、Solana、Sui、Move、AI 和安全开发者。它偷的也不是无关紧要的数据，而是 SSH key、GitHub token、AWS 凭证、钱包、浏览器数据、环境变量和 API key。

更值得 AI 开发团队注意的是，它还会利用 AI 编程助手的工作方式。

新风险不在模型里，而在工作流里

传统供应链攻击已经很熟悉：恶意 npm 包通过 postinstall 执行脚本，PyPI 包在 import 时触发逻辑，Rust crate 通过 build.rs 在构建时运行代码。开发者一安装、一导入、一编译，攻击就开始了。

TrapDoor 在这个基础上又往前走了一步。The Hacker News 引述 Socket 的研究称，部分载荷会向项目里写入 .cursorrules 和 CLAUDE.md，里面带有隐藏指令，诱导 AI 助手执行所谓“安全扫描”，实际结果可能是发现并外传本地机密。

这件事麻烦的地方在于，开发者平时确实希望 AI 读这些文件。

CLAUDE.md 里写项目规范，合理；.cursorrules 里写代码风格，合理；AGENTS.md 里写执行边界，也合理。问题是，AI 助手不会只看“我们自己写的那部分”。只要文件被污染，或者依赖包、PR、脚手架把隐藏内容带进仓库，AI 就有机会把攻击者的指令也当成上下文。

对 AI 团队来说，危险点变了

过去我们做安全检查，重点常放在代码、依赖和生产环境。现在还要把“AI 会读什么”列入检查范围。

一个真实的 AI 开发环境里，往往有这些东西：

位置	可能暴露什么
本机 shell	SSH key、GitHub token、云厂商凭证
`.env` 文件	数据库、模型 API、支付和邮件服务密钥
CI 配置	部署 token、npm token、镜像仓库凭证
AI 说明文件	项目规范、允许执行的命令、测试和发布流程
依赖安装脚本	安装时自动执行的外部代码

如果 AI 助手有自动执行权限，风险会更高。它可能按说明运行命令、读取文件、安装包、提交修改。开发者本来省掉了许多确认步骤，但攻击者也因此少了一些阻力。

这不是说 AI 编程助手不能用。真正的问题是，很多团队已经把它当成团队成员，却还没有给它配同等级的权限管理和审查流程。

现在可以做的五件事

第一，检查仓库里的 AI 指令文件。

把 CLAUDE.md、.cursorrules、AGENTS.md、.cursor/、.claude/ 这类文件列入代码审查范围。它们不是普通说明文档，而是会影响工具行为的配置。来自外部 PR、模板仓库、依赖包示例项目的这类文件，更要单独看。

第二，查看不可见字符。

TrapDoor 相关报道提到过零宽 Unicode 字符。普通编辑器里，人眼可能看不到，但模型和工具会读到。团队可以在 CI 或本地脚本里检查零宽字符、Unicode tag、异常控制字符。发现后不要直接忽略，先确认它为什么存在。

第三，限制自动执行权限。

自动模式很方便，但不应该在所有仓库、所有命令、所有目录里默认开启。对陌生仓库、刚 clone 的开源项目、带安装脚本的新依赖，先用只读模式看一遍。需要执行命令时，把高风险命令单独确认，例如读取 home 目录、上传文件、访问云凭证、安装全局包、改 shell 配置。

第四，减少本机密钥暴露。

把长期有效的云密钥、GitHub token、npm token 从日常开发机里挪走，能用短期凭证就不要用长期凭证。.env 不要随手放一堆生产密钥。模型 API key、支付 key、对象存储 key 这些东西，一旦被本地脚本读走，影响范围往往比一次代码错误更大。

第五，把依赖安装当成高风险动作。

不要只看包名像不像。看发布时间、维护者、下载量、仓库链接、install 脚本、构建脚本和近期版本变化。AI 推荐的包也一样要查。AI 能帮你找到库，但不能替你承担供应链风险。

这件事对产品团队也有意义

TrapDoor 看起来是开发者安全事件，但产品团队也应该关心。

很多 AI 产品的开发节奏越来越快：一个人拉需求，一个人写 prompt，一个 AI 助手改代码，再加一堆现成 SDK 和模板。速度变快以后，团队更容易把“能跑起来”当成阶段目标，却忘了问三个问题：

1. 这个仓库里有哪些文件会改变 AI 助手行为？
2. AI 助手能不能读取或外传敏感信息？
3. 依赖安装、测试、构建过程中有哪些自动执行脚本？

这三个问题不只属于安全工程师，也属于每个负责交付的人。

最后

AI 编程助手最大的价值，是把重复开发、代码迁移、测试修复这些工作变快。但它越像一个能执行任务的同事，就越需要边界。

TrapDoor 值得关注，不是因为它用了多新奇的恶意代码，而是因为它击中了一个正在扩大的习惯：我们让 AI 阅读项目、相信项目、执行项目里的说明。

以后评估一个 AI 开发流程，不要只问“模型准不准、代码能不能过测试”。还要问一句：这个 AI 助手到底被谁指挥？

参考来源：AIHOT 2026-05-25 日报、The Hacker News 对 TrapDoor 的报道、VibeAudits 对 CLAUDE.md 攻击面的整理。