这可能是人工智能开发者最不愿看到的消息：你用来构建未来世界的工具，正在悄无声息地偷走你的密码。
而把“钥匙”弄丢的，恰恰是微软自己。
当“后院”起火：微软自家的开源项目被黑了
一夜之间，微软紧急下架了超过70个托管在GitHub上的开源项目。
不是功能更新，不是例行维护，而是因为黑客潜入了这些代码仓库，并注入了专门窃取密码的恶意软件。
更尴尬的是，这些项目不是什么边缘工具。它们大多直接服务于微软的云服务Azure，以及AI开发者们天天用的利器：Claude Code、Gemini命令行界面、VS Code……
换句话说，攻击者精准地瞄准了AI时代“军火库”的供应商。
投毒的代码，沉默的微软
攻击的原理被安全公司Cloudsmith和OpenSourceMalware率先披露，听起来简单却致命：恶意代码被伪装成项目依赖项，当开发者在AI编码应用中打开这些项目时，恶意软件就会自动运行，窃取账户密码和敏感凭证。
这无异于在程序员的工位上安装了一个隐形摄像头，记录下他输入的每一个机密字符。
微软发言人Ben Hope的回应显得谨慎而有限：“我们已暂时移除部分代码库进行调查，并已通知少量可能受影响的客户。”
但关键的数字——具体有多少开发者已经“中毒”——微软至今没有披露。在供应链攻击中，“少量”是一个模糊到令人不安的词。
供应链攻击：黑客的“最优解”
这次事件，是典型的“供应链攻击”。
攻击者不费力去攻打一个个坚固的堡垒（个人开发者或大公司的系统），而是直接污染源头工厂（开源项目）。只要工厂的零件被装上木马，所有使用这些零件的产品都会跟着沦陷。
正如一位热门评论所言：“请有人解释一下，怎么可能向这么多代码库中添加被混淆的文件？难道他们没有任何代码审查吗？”
这正是供应链攻击的可怕之处。它利用的是信任链——开发者信任微软的官方项目，所以下载、使用，却不知信任本身已被恶意代码篡改。
老实讲，瞄准开源项目不是新鲜事，但瞄准微软这种量级巨头的项目，并且短时间内连环得手，就非常罕见了。
不是第一次：旧伤未愈，又添新痕
最让安全圈感到不安的，是这次事件的“续集”属性。
这已经是微软几周内第二次被曝出开源项目遭入侵。上一次是名为“Durable Task”的开发工具项目在5月中旬被黑。
而OpenSourceMalware直接指出，这次攻击是对“Durable Task”项目的“再次攻破”。
这意味着要么，微软上次根本没清理干净后门；要么，黑客用新的方式再次渗透。 无论哪种可能，都指向一个危险的事实：在面对这类定向攻击时，巨无霸的防御体系也可能出现盲区。
这点我不太认同某些声音把问题简单归咎于“开源模式”，但微软的应急响应和清理能力，确实被画上了一个问号。
社区在恐慌，真实用户在遭殃
新闻下方，比事故本身更鲜活的是用户的真实经历。
“我昨天不得不重置了我的个人微软账户密码，因为收到了来自罗马尼亚的登录双重验证警报。我唯一的微软产品是一台Xbox。即使在AI时代之前，微软的泄露也像个筛子。”
这位用户的评论让事件从抽象的“安全漏洞”落地为具体的个人恐惧。它揭示了一个深层焦虑：即使是与AI开发无关的普通用户，也可能因为安全边界的模糊而被波及。
另一条高赞评论点出了技术层面的愚蠢：“如果你准备把访问令牌交给在奇怪开源项目上运行的AI代理，你至少应该使用细粒度权限的令牌。允许使用经典令牌简直让我震惊。”
安全建议与实际操作的脱节，在这里暴露无遗。 开发者们在追求效率和便捷时，可能无意中绕过了基本的安全闸门。
错配的信任与不对称的战争
我们是否“过度信任”了这些科技巨头提供的工具？
一位用户的反问很尖锐：“我们还能相信这些人掌握着我们安全启动（Secure Boot）中的根证书吗？”
这把一次代码投毒事件，上升到了对整个数字世界信任根基的质疑。当微软这样的“守门人”自身出现安全瑕疵，其连锁反应远超代码本身。
个人觉得，这次事件最值得玩味的矛盾在于：微软一边全力打造Copilot等AI开发工具，致力于构建一个AI原生的开发环境；另一边，其维护这个环境安全的基础工具链却连续失守。 这像极了在精心装修宫殿时，忘了加固地基。
战斗是不对称的。黑客只需成功一次，而防御者必须永远正确。
【锐评】：这不是一次普通的技术漏洞，这是AI军备竞赛的“大后方”被撕开了一道口子——当造工具的人都不安全，用工具的人该何去何从？
参考链接：
https://techcrunch.com/2026/06/08/microsofts-open-source-tools-were-hacked-to-steal-passwords-of-ai-developers/