微软把70多个GitHub仓库临时关停，这个动作本身已经说明问题不在“单点漏洞”，而在整个开发链路的可信边界开始失稳。
这次被卷入的并不是边缘项目，而是Azure相关服务代码，以及一批专门给AI编程工具使用的辅助仓库——包括Claude Code、Gemini CLI、Cursor、VS Code这类开发者日常高频依赖的工具链。换句话说，攻击不是发生在应用层，而是直接切进了“AI辅助开发”的输入源头。
Miasma蠕虫的特点也很清晰，它并不只是传统意义上的代码注入，而是围绕AI编程场景做了适配：当开发者在AI助手中加载被污染的仓库时，恶意代码会被触发执行。触发点不再是“运行代码”，而是“让AI理解代码”。
这中间的差别很关键。过去的供应链攻击依赖人工执行路径，现在则开始依赖模型的读取行为。
事件的起点可以追溯到5月中旬的一次GitHub内部代码泄露。当时黑客组织Teampcp通过微软应用商店上架带毒VS Code扩展程序，利用一名GitHub员工在短时间内下载扩展的窗口期，获取凭证和密钥，随后横向进入内部系统。据披露，约3800个内部仓库被访问或窃取。
后续发生的事情更像是“权限二次利用”。攻击者拿到微软贡献者token之后，并没有立即破坏，而是持续向官方仓库注入恶意代码。Miasma蠕虫正是在这个阶段开始扩散，它依赖的是开发者的正常行为路径，而不是传统意义上的漏洞利用。
问题也因此变得更棘手：感染入口不是用户点击的未知链接，而是开发者日常使用的AI编程助手。
AI coding工具在这里并非直接受害者，而是放大器。当模型被用来读取代码、解释结构、甚至自动补全逻辑时，它同时也在处理可能已经被污染的输入。这种“语义级执行环境”让传统安全边界变得模糊——代码是否安全，不再只取决于静态扫描，而取决于模型是否被当成执行链的一部分。
安全机构给出的提醒比较克制，但方向很明确：在AI助手中直接运行未知仓库，需要重新评估风险模型。
问题不只是“不要运行恶意代码”，而是“AI已经成为代码执行前的第一解释器”。一旦输入层被污染，模型可能在无意间放大攻击面，甚至协助攻击者理解目标系统结构。
从结构上看，这次事件更像一次开发生态的压力测试。GitHub、扩展市场、AI编程助手、企业内部仓库，这些原本分层的系统正在被压缩到同一条工作流里，而攻击路径也顺势变成一条连续链。
当代码阅读本身变成攻击入口，安全问题就不再停留在仓库层面，而是进入“开发认知链”的阶段。
