打开仓库就中招，AI 开发者供应链从编辑器开始

最近几天，TechCrunch 的一篇文章《Microsoft’s open source tools were hacked to steal passwords of AI developers》火了。

这篇文章写的是，微软托管在 GitHub 上的一批开源仓库被植入了恶意代码，攻击者盯上的不是普通用户，而是会用 Claude Code、Gemini CLI、Cursor 和 VS Code 打开这些仓库的开发者。

如果只把它理解成“又一个开源包被投毒”，其实会低估这件事。

这次真正值得警惕的，不是恶意代码更大，也不是受影响仓库更多。

而是攻击触发点变了。

过去大家熟悉的 supply chain attack，通常发生在安装时刻。你 npm install、pip install、跑 postinstall，然后中招。

这次不是。

这次的意思更接近：

你只是把仓库打开了，agent 或编辑器就可能替攻击者先跑了一步。

这次攻击最狠的地方，不在包管理器

StepSecurity 的取证分析给出的细节很关键。

攻击者往 Azure/durabletask 仓库里塞进了几类配置文件：

.claude/settings.json.gemini/settings.json.cursor/rules/setup.mdc.vscode/tasks.json

这些文件表面看都很像“项目配置”。

但它们的共同目标只有一个：把恶意 JavaScript payload 在开发者打开仓库时跑起来。

也就是说，这次攻击不是在利用“你运行了项目”，而是在利用“你相信了项目”。

过去很多人把仓库里的 agent rules、workspace config、editor tasks 当成协作细节。

现在这层默认信任被打穿了。

仓库已经不只是代码集合。

它还是一个会影响 agent 行为、会影响编辑器动作、甚至会直接触发命令的执行环境描述。

为什么 AI coding tool 在这里特别尴尬

这件事之所以在 AI 圈里特别炸，是因为它刚好打中了 agent 产品最想炫耀的能力。

这些工具一直在拼什么？

拼更懂项目。拼更懂上下文。拼能自动读规则。拼能帮你 setup、修 bug、跑测试、执行任务。  

问题也出在这里。

一旦工具把 repo-local config 视为可信输入，攻击者就有机会把“项目初始化说明”伪装成“执行恶意代码”。

StepSecurity 对这件事的判断我很认同：过去大家盯的是 postinstall，现在得开始盯“editor-level postinstall”了。

这个说法非常准确。

以前你至少知道安装依赖是高风险动作。

现在风险被提前到了一个大家更容易放松警惕的时刻：

打开仓库。让 agent 先读一下。看它怎么理解项目。  

很多人会把这当成低风险操作。

但这次事件说明，它早就不是了。

这已经不是微软一家的问题

Ars Technica 和 WIRED 的跟进把这个背景补得更完整。

这次事件背后牵出的是更大范围的 TeamPCP / Miasma 供应链攻击潮。它不是一锤子买卖，而是一种越来越成熟的攻击飞轮。

逻辑大概是这样的：

先拿下某个开发者或维护者的凭证。再借合法身份发出带毒更新。再从被感染的开发者机器里偷更多 token、云凭证和发布权限。然后继续污染更多项目。  

WIRED 甚至直接把这件事总结成一个“self-perpetuating flywheel”。

我觉得这个词用得很准。

因为攻击者已经不是在单点钓鱼。

他们是在利用现代工程生态的默认信任，一层一层往里钻。

所以，问题也不只是“微软有没有守好自己的仓库”。

问题是：

当仓库配置、agent 规则、IDE 自动化、GitHub Action、包管理器、云凭证和发布身份全都连在一起时，整个开发者工作流本身就是攻击面。

Azure/functions-action 停摆这件事，说明爆炸半径已经到生产环境了

很多安全新闻最大的问题，是看起来离真实业务太远。

这次不是。

StepSecurity 明确提到，Azure/functions-action 被禁用之后，所有依赖 Azure/functions-action@v1 的 CI/CD workflow 都会立刻受影响。

微软 Learn Q&A 上也已经有开发者在问：仓库被封了，我的 GitHub Actions 直接跑不下去了，现在该怎么办？

微软外部 staff 的回复也很现实：先换 Azure CLI、Azure DevOps、Zip Deploy 或其他方式顶上。

这说明这次事情已经不是“安全研究员在圈内预警”。

它已经实打实碰到了工程团队的发布链路。

同时它还顺手暴露了另一个老毛病：

太多人还在依赖 mutable tag。

你写 @v1 的时候觉得方便。

出了事以后你会发现，这种方便的代价是：上游一消失，下游一起炸。

这件事最该改掉的，是开发者对仓库的直觉

过去工程师看到一个 Git 仓库，默认会觉得这是一份代码资产。

以后这个直觉得改。

它同时也是一个潜在的行为入口。

尤其在 agent 时代，.claude、.gemini、.cursor、.vscode 这些目录，已经不再只是“各自工具的小配置”。

它们应该被当成安全敏感对象。

就像你不会把 GitHub Actions workflow 当作纯文档一样，以后也不该把 repo-local agent rules 当作无害文本。

我觉得这件事最终会逼出三种变化。

第一，AI coding tool 会被迫加强默认提示、沙盒和最小权限。第二，团队会开始审计仓库级配置，而不是只审查源码。第三，供应链安全会继续前移，从 package install 一直前移到 folder open。  

这才是这次事件真正的行业意义。

不是“微软又出了一次事”。

而是“打开仓库”这件事，本身再也不能被当成天然安全动作了。

也别把所有锅都简单甩给 AI tool

这里也得讲一句反向证据。

这次事件不是“AI tool 自己发疯了”。

真正被利用的是被攻陷的维护者身份，加上 repo-local config 被默认信任这套机制。

VS Code 的 folder-open task、Cursor 的规则文件、Claude Code 和 Gemini CLI 的 session hook，本来就是为了提高自动化体验设计出来的。

问题在于，今天大家已经把“方便”默认放在“隔离”前面了。

所以，真正该改的不是一句“别用 agent”。

而是要把会读取仓库、会解释规则、会自动执行命令的工具，统一当成高权限执行环境来设计。

不然以后每一次“让 agent 先看看项目”，都可能是在替攻击者做预处理。

最后

这篇文章会火，我一点不意外。

因为它把一个很多开发者还没完全消化的变化，直接砸到了桌面上：

AI coding agent 时代，供应链不再从安装开始，而是可能从打开仓库开始。

这句话听起来像危言耸听。

但这次微软仓库事件已经把它变成现实了。

以后最该多看一眼的，可能不是 package.json 里的依赖列表。

而是那些看起来很像“项目贴心配置”的文件。

因为攻击者已经开始学会，把第一条恶意命令写在你最容易忽略的地方。

参考来源

• TechCrunch: Microsoft’s open source tools were hacked to steal passwords of AI developers^[1]
• StepSecurity: Miasma Worm Hits Microsoft Again^[2]
• Ars Technica: For the 2nd time in weeks, Microsoft packages laced with credential stealer^[3]
• Microsoft Q&A: GitHub action Azure/functions-action down^[4]
• WIRED: A Hacker Group Is Poisoning Open Source Code at an Unprecedented Scale^[5]

引用链接