夜雨聆风
上周五晚上，我像往常一样刷着 X（推特），看到 Socket 安全团队发了一篇分析报告。
看完第一段，我后背一凉。
这不是那种「又来一个漏洞」的麻木感，而是——攻击者正在利用你每天使用的 AI 编程助手，从你眼皮底下偷走你的 SSH 密钥、云凭证、甚至加密货币钱包。
而我说的「利用」，不是你想象的「黑客黑进了 AI 服务器」。
更可怕。
他们在向你的 AI 助手「下毒」
先说一下发生了什么。
2026年5月22日到25日，一个代号 TrapDoor 的供应链攻击在 npm、PyPI、Crates.io 三大包管理器上同时爆发。36个恶意包、384个版本，全部经过精心伪装。
包名长这样：async-pipeline-builder、eth-wallet-sentinel、defi-risk-scanner、llm-context-compressor……
看上去都是一个正经开发工具该有的名字，对吧？
但它们一装进你的项目，就开始偷东西：SSH 密钥、AWS 凭证、GitHub token、浏览器密码、Su钱包、Solana 钱包、环境变量里的 API key……只要是值钱的，它全要。
这是常规操作，不算新鲜。
真正让我后背发凉的是它的持久化手段。
攻击者发现了一个全新的攻击路径——向开源项目提交 Pull Request，注入被操纵的 .cursorrules 和 CLAUDE.md 文件。
等等。
你就是用 Cursor 写代码的，你就是用 Claude Code 做代码审查的。
那这两个文件是干什么用的？
简单说：它们是 AI 编程助手的「系统指令」。
.cursorrules 告诉 Cursor 这个项目有什么约定、用什么框架、代码风格是什么。CLAUDE.md 告诉 Claude Code 这个项目的结构、构建命令、测试流程。
攻击者的思路非常刁钻：
- 1. 向
browser-use、langchain、llama_index这些流行的 AI 项目提交 PR - 2. PR 标题写得人畜无害——「docs: add .cursorrules with dev standards and build verification」
- 3. 里面塞了用零宽 Unicode 字符隐藏的恶意指令
- 4. 当开发者
git clone这个仓库，打开 Cursor 或 Claude Code - 5. AI 助手自动读取这些「配置」，把它们当作可信指令执行
- 6. 于是 AI 在毫不知情的情况下，替攻击者跑了一个「安全检查」——实际上是在偷你的数据
不是黑客黑了你。是你最信任的 AI 助手，在替黑客干活。
这感觉就像你家的智能门锁，被人在固件里塞了一行「深夜自动开门」的代码。
这不是科幻，已经在发生了
你可能觉得「我没装那些恶意包，跟我没关系」。
那我要告诉你一个更让人不安的事实：这次攻击不是孤立事件。
从今年3月开始，一个代号 TeamPCP 的黑客组织就在系统性攻击 AI 开发生态。
他们干过的事：
3月19日，攻破 Aqua Trivy（安全扫描工具）的 GitHub Actions，在 76/77 个 tag 里植入后门。
3月23日，攻破 LiteLLM（最流行的 AI 代理网关），在 PyPI 上发布了带后门的 1.82.7 和 1.82.8 版本。这个包被下载了 9500 多次。 它用的是 Python 的 .pth 机制——你甚至不用写 import litellm，只要 pip install 完成，恶意代码就已经执行了。
而且 LiteLLM 是个「中间人」工具——它帮你路由 API 请求到 OpenAI、Anthropic 等模型。这意味着，一个组织的所有 AI API 密钥，都在它手里过。
3月27日，攻破 Telnyx（通信 API 平台）。
4月22日，攻破 Xinference（AI 推理平台）。
5月11日，最炸裂的一波——TeamPCP 在 6 分钟内，向 TanStack 的 42 个 npm 包推送了 84 个恶意版本。TanStack 的 react-router 一个月有 1200 万次下载。你去算这笔账。
5月12日，攻破 guardrails-ai（LLM 输出安全过滤），在 PyPI 上发布恶意版本 0.10.1。这个包干的事特别「专业」：它在 178 个 .py 文件的 __init__.py 末尾追了 14 行加载代码，从远程拉一个 23KB 的 Python zipapp 载荷。
这个 zipapp 叫 transformers.pyz——冒充 HuggingFace 的 Transformers 库。里面装了 7 个凭证收割模块，扫描 AWS、Azure、GCP、Kubernetes、HashiCorp Vault 等 90 多个凭证文件路径，还自带 systemd 持久化。
OpenAI 自己都被感染了。 他们事后披露，有两台公司设备受到了影响，应用程序签名密钥（Windows、macOS、iOS、Android）全部泄露。
所以，这不是「可能发生」的事。这是已经在发生的事。
为什么这次不一样？
我们见过 npm 投毒、见过 PyPI 冒名包、见过 GitHub Actions 被滥用。
但这次有几点完全不同。
第一，攻击面从「代码」扩展到了「AI 配置」。
以前你 npm install 一个恶意包，最多就是运行了它的 postinstall 脚本。现在不一样了：攻击者往你的项目里塞一个 .cursorrules，你打开 VSCode 的瞬间，Cursor 就帮你执行了恶意逻辑。
这个攻击面以前不存在。因为两年前还没有 Cursor、没有 Claude Code、没有这么大规模的 AI 编程助手普及。
第二，这是第一次供应链攻击把「AI Agent 配置文件」当作持久化手段。
TeamPCP 在 LiteLLM 攻击中用了一招很恶心的手法：感染后，它在 .claude/settings.json 和 .vscode/tasks.json 里植入钩子。这样即使你删除了恶意包、清除了 lockfile，下次打开项目——AI 助手又把恶意代码跑了一遍。
卡巴斯基去了就没了，但 AI 在那儿。
第三，攻击者正在 AI 辅助下「工业化」生产攻击。
Socket 团队分析 TrapDoor 的 GitHub 活动时发现了一个细节：攻击者的仓库里有大量 AI 辅助生成的痕迹——安全工具脚手架、通用 lure 仓库、prompt injection 文档、部分实现的提取框架。这不再是「一个人在键盘前敲代码」的传统黑客，而是用 AI 生产攻击的黑客。
说句不好听的：你每天用 AI 写代码、写测试、写文档，他们用 AI 写恶意包、写钓鱼 PR、写 bypass 方案。同一套工具，完全相反的用途。
三个你必须马上做的事
我不是安全专家，也没有完美的解决方案。但下面三条是我自己已经在做的，你可以参考。
第一点：给 npm install 加一层保险。
pnpm v10 默认已经禁止 install scripts 自动执行。如果你还在用 npm，建议换成 pnpm，并且在 pnpm-workspace.yaml 里加上这个配置：
minimumReleaseAge: 10080 # 新包至少发布7天才能安装
trustPolicy: no-downgrade # 禁止版本降级这两行就能挡住大部分通过新版本身份投毒的恶意包。
第二点：检查你的项目里有没有被篡改的 AI 配置文件。
打开终端，跑一下这几行：
# 检查 .cursorrules 是否被修改过
git diff HEAD -- .cursorrules
# 检查 CLAUDE.md 是否被修改过
git diff HEAD -- CLAUDE.md
# 检查 VSCode 任务配置
git diff HEAD -- .vscode/tasks.json
# 检查 Claude 配置
cat ~/.claude/settings.json如果你发现里面有你不认识的 URL、hook、或者像 P-2024-001 这样的标记串——别犹豫，立刻断网，通知安全团队。
第三点：不要信任 AI 配置文件。
这个说起来有点讽刺——AI 编程助手的核心卖点就是「自动读取项目配置，理解你的代码」。但 TrapDoor 告诉我们，这个功能本身就是攻击面。
我个人建议的做法是：
- • 从开源项目 clone 代码后，先删掉
.cursorrules和CLAUDE.md，用自己的配置替代 - • 在 CI 中加一个步骤，检查这些文件是否包含远程 URL 或可执行钩子
- • 如果团队用统一的 AI 配置，放在内部 wiki 里手动维护，不要放在仓库里自动加载
说到这，我突然想起《沙丘》里的一个意象。
书里的沙虫平时在地下深处沉睡，但只要地面出现有规律的震动——比如人类的脚步声——它就会破土而出，吞噬一切。
你看像不像？
Claude Code、Cursor、Copilot……这些 AI 编程助手就是地面的「规律震动」。它们越来越普及，越来越深入开发者的日常，以至于我们开始理所当然地信任它们读取的每一个文件、执行的每一个命令。
而攻击者，就是那个学会了模仿脚步声的人。
他们不需要攻破 AI 服务器的防火墙，不需要找到零日漏洞。只需要在 npm 上放一个包装精美的恶意包，或者往开源项目里塞一个「人畜无害」的配置文件，就能让 AI 帮他们完成剩下的工作。
攻击者不需要入侵你的系统。他们只需要让你信任的 AI，替他们开门。
《沙丘》里的弗雷曼人有一个生存法则：永远不要在同一片沙地上踩出两次相同的脚步声。
对现在的我们来说，这条法则可以翻译成：永远不要盲信 AI 自动读取的任何东西。
每次 npm install 之前，想一想这个包是谁维护的。
每次 AI 助手自动执行一个「安全检查」之前，看一看它到底在干什么。
每次打开一个新的开源项目之前，检查一下那些「看不见的配置文件」。
小心那些让你感到舒适的自动化。
因为最危险的陷阱，看起来都像一条通向便利的路。
文中提到的 IOC（入侵指标）：
- • 攻击者 GitHub:
ddjidd564- • 标记串:
P-2024-001- • 载荷:
trap-core.js- • C2:
ddjidd564[.]github[.]io/defi-security-best-practices/- • 持久化路径:
.cursorrules,CLAUDE.md,.claude/settings.json,.vscode/tasks.json信息来源：Socket.dev TrapDoor 分析报告、Unit 42 Mini Shai-Hulud 分析、Wiz 安全团队 TanStack 事件复盘、CSA 研究笔记。
这篇文章的内容已经够让你不安了。但说实话，我写的时候自己都觉得——这些东西的传播速度，可能比我们想象的快得多。
如果你觉得有参考价值，欢迎转发给身边用 AI 写代码的朋友。也许早一天看到，就能躲过一劫。
也欢迎在评论区聊聊——你平时会检查 AI 配置文件吗？有没有遇到过可疑的情况？
作者：凡哥
