两款看起来完全合法的常用 VS Code 插件刚刚上演了我调查过最复杂的供应链攻击。如果你是一名开发者，很有可能你已经中招了。
数据触目惊心：总计 150 万次安装 。两款插件运行起来都毫无瑕疵，提供的 AI 编程辅助功能与宣传的一模一样。而这恰恰是它们最危险的地方。
当你正忙着敲代码、开发新功能时，这些插件却在后台悄无声息地搜刮你打开的每一个文件、记录你的每一次按键，并将所有内容传输到位于中国的服务器。没有警告，没有授权弹窗。只有一场沉默而系统性的窃取。
让我带你看看事情的真相，因为这不仅仅是又一个"安全警示"，它更是现代供应链攻击的教科书式案例，揭示了为什么你的开发环境可能是整个安全防护体系中最薄弱的一环。
完美伪装：功能强大的"良性"插件
这就是被 Koi Security 的安全研究员命名为"恶搞柯基（MaliciousCorgi）"行动真正令人感到恐怖的地方：这两款插件确实提供了价值。
安装 ChatGPT --- 中文版 或 ChatMoss，你确实能得到正儿八经的 AI 代码建议。询问关于代码的问题，你会收到准确且有帮助的回答。自动补全很丝滑，错误解释也合情合理。一切功能都表现得像一个现代 AI 编程助手该有的样子。
这不是那种会导致 IDE 崩溃或满屏弹窗的拙劣恶意软件。攻击者明白一个核心道理：功能性等于信任。当一个工具兑现了它的承诺，开发者就会放下戒备，不再追问。
这两款插件都顺利通过了微软的市场审核流程。它们累积了超过一百万次的下载量，在 VS Code 官方市场上公开存在了数月之久，甚至还收获了大量不知情用户的五星好评，而这些用户完全没意识到自己运行的是间谍软件。
三大隐秘通道，一场毁灭性打击
在提供宣传中的 AI 功能之余，这些插件在后台静默运行着三个并行的辅助数据采集机制。你可以把它们想象成从不同角度钻入你开发环境的抽油井。
通道 1：实时文件监视
- 触发机制 ：只要你在 VS Code 中打开任何文件（无需编辑或保存），插件就会读取其全部内容。
- 操作方式：文件内容会被 Base64 编码，并传输到一个隐藏的追踪 iframe 中。
- 监控力度 ：正常的 AI 自动补全仅需光标周围约 20 行上下文，但这些插件会抓取每一份文件，且在每次通过
onDidChangeTextDocument事件进行编辑时都会重复此操作。 - 泄露内容：你的核心算法、构建数周的 API 集成、甚至是写给自己的临时处理方案注释，都被发送到了未经授权的服务器。
通道 2：服务器受控的精准收割
- 机制：插件维持着一个命令控制通道（C&C），随时等待指令。
- 指令执行 ：当服务器发送类似
{"type": "getFilesList"}的 JSON 指令时，插件会从你的工作区批量抓取多达 50 个文件。 - 目标选择 ：这种抓取并非随机，而是极具针对性地锁定除图片以外的所有内容，包括数据库凭证、包含 API 密钥的
.env文件、AWS 访问令牌和 SSH 私钥。 - 隐蔽性：整个过程完全静默，没有进度条，没有通知，你根本察觉不到整个项目正在被有计划地窃取。
通道 3：画像引擎
- 技术手段：插件的 webview 中嵌入了一个完全透明且不可见的零像素 iframe。
- 专业平台：该 iframe 加载了诸葛 IO（Zhuge.io）、GrowingIO、TalkingData 和百度统计四个商业分析平台。
- 深度分析：这些企业级系统旨在构建全面的用户画像，追踪你的身份、地理位置、所属公司、核心项目以及日常活动模式。
- 攻击意图：画像引擎会告诉攻击者哪些人的文件最值得偷。如果你身处头部科技公司或独角兽企业，或者是负责核心基础设施的高级工程师，你的工作区将成为高价值目标。
这是一种在开发者层面实施的典型供应链攻击方法：先画像，再窃取，最后将其武器化。
为什么这次攻击能大获全胜（以及这对你意味着什么）
AI 编程助手从根本上改变了开发者工具的信任模型。这些插件为了实现其功能，必须获得广泛的访问权限。它们需要读取你的代码来提供建议，也需要理解你的项目结构来给出相关的回答。
这种合法的需求为恶意行为提供了完美的伪装。你该如何区分一个 AI 助手是在读取 20 行上下文，还是在窃取整个文件？你又该如何分辨是有益的数据分析还是侵入性的用户画像？ 除非使用专业的安全工具，否则你根本无法区分，而大多数开发者并不会运行这类工具。
VS Code 市场采取了多重安全措施：包括多种杀毒引擎的恶意软件扫描、异常使用模式监测、名称抢注预防以及插件签名验证。然而，这些插件通过了所有审核。
究其原因，是因为功能完善的恶意软件看起来与合法软件无异。其代码运行正常，行为逻辑合理，发布者看起来也完全可信，没有任何明显的危险信号。这就是当下的新现实：恶意插件不再需要看起来鬼鬼祟祟，它们只需要"好用"就行了。
更广泛的趋势：你的 IDE 已沦为攻击目标
"恶搞柯基（MaliciousCorgi）"行动并非孤立事件。它是针对开发环境日益升级的连环攻击中的一部分。
- 官方清理：仅在 2025 年，微软就从 VS Code 市场中移除了 110 个恶意插件。
- GlassWorm 行动：该攻击劫持了多个 OpenVSX 插件，将其转化为自传播蠕虫，在 36,000 次安装中窃取了来自 GitHub、npm 和加密货币钱包的凭证。
- Shai-Hulud 蠕虫：它攻击了 npm 生态系统，向 100 多个包注入了自复制恶意软件，用于抓取令牌并自动发布到更多包中。其第二版更加激进：如果窃取凭证失败，它会尝试摧毁受害者的整个家目录。
- PackageGate 漏洞：在 npm、pnpm、vlt 和 Bun 中发现了 6 个零日漏洞，这些漏洞能绕过 lockfile 完整性检查并自动执行恶意代码。pnpm 修复了两个严重漏洞（CVE-2025--69263 和 CVE-2025--69264），而微软旗下的 npm 却以"行为符合预期"为由关闭了漏洞报告。
你看清其中的规律了吗？攻击者正在系统性地瞄准开发者供应链的每一个环节。无论是包管理器、IDE 插件还是构建工具，只要是代码流经的开发环节，现在都被视为可利用的攻击面。
这些攻击之所以屡屡得手，是因为我们的开发工具在设计初衷上优先考虑的是便捷性，而非安全性。
你现在应该立刻采取的操作
如果你正在阅读本文且电脑上安装了 VS Code，请按照以下紧急行动计划执行：
第一步：检查是否存在恶意插件
打开 VS Code 并进入"扩展（Extensions）"面板，搜索以下插件：
- ChatGPT --- 中文版（发布者：WhenSunset）
- ChatMoss 或 CodeMoss（发布者：zhukunpeng）
如果你发现了其中任何一个，请立即将其卸载。
第二步：假设环境已失守
如果你曾安装过上述任一插件，请务必视工作区内的所有凭证为已泄露状态。这意味着你必须采取以下补救措施：
- 更替所有的 API 密钥和访问令牌
- 更改数据库密码
- 重新生成 SSH 密钥
- 撤销并重新签发云服务凭证（如 AWS、GCP、Azure 等）
- 审查过去几个月的云服务商日志，排查是否存在未经授权的访问记录
没错，这确实很痛苦。但比起几个月后才猛然发现有人一直在盗用你的 AWS 凭证挖掘加密货币，或者发现你的核心专利算法出现在了竞争对手的产品中，现在的这点麻烦显然要轻得多。
第三步：审计你的其他插件
你现在安装了多少个插件？你还记得当初为什么要安装它们吗？你确切知道每一个插件都在后台做些什么吗？
请逐一过遍你的插件列表，并针对每一个插件自问以下问题：
- 它最后一次更新是什么时候？
- 它的安装量有多少？
- 发布者是否经过验证，或者至少是你认识的可靠来源？
- 它请求的权限是否超出了其宣称功能所需的合理范围？
请移除所有你并非活跃使用的插件。请记住，每一个插件都是一个潜在的攻击面。
构建更稳固的防御体系
个人的警惕虽然有帮助，但还远远不够，这个问题需要系统性的解决方案。
-
对于开发团队：建议实施插件白名单制度。
- 创建一份经过安全团队审核的核准插件清单。
- 在将新插件加入白名单前，利用 ExtensionTotal 或 VScan 等工具进行风险评估。
-
对于企业组织：可以使用集中化的插件管理工具（如 JFrog 的 IDE Extensions Control）。
- 这类工具提供经过审核的本地缓存仓库。
- 能够防止开发者安装未经授权的附加组件。
-
对于个人开发者：对插件采取"零信任"心态。
- 高下载量并不等同于安全，功能好用也不代表值得信任。
- 功能性与安全性是两种完全独立的属性。
- 监控更新：长期停更的项目突然发布新版本是一个危险信号，这可能意味着账号已被劫持。
- 审查改动：开启插件更新通知，以便在自动更新前查看具体改动内容。
- 环境隔离：针对不同的工作场景使用独立的 VS Code Profile。
- 保持纯净：在处理敏感项目时使用仅含最少插件的纯净配置；而那些插件成堆的配置仅用于实验和学习，而非生产工作。
展望未来
截至 2026 年 1 月 26 日，"恶搞柯基（MaliciousCorgi）"的两款插件仍可在 VS Code 市场上获取。虽然微软安全团队已收到通知，这些插件最终会被移除并加入黑名单以触发自动卸载，但这终究是亡羊补牢，而非未雨绸缪。
新的攻击行动可能已经在某处悄然展开，它们使用不同的发布者账号、不同的插件名称，甚至更先进的技术。攻击者在每一次迭代中都在学习。
现在的问题不再是是否还会发生此类攻击，而是开发者和企业能否足够快地转变安全习惯来应对威胁。你的开发环境现在就是基础设施，请务必审计它、监控它，并应用与生产系统同等严苛的安全纪律。
因为下一次，受害者可能不再是 150 万开发者，而仅仅是你自己。等到你察觉时，你的代码、凭证以及公司的知识产权，或许早已易手。
你的团队在安装插件前是如何进行审核的？欢迎在评论区分享你的做法，我很想知道不同组织是如何应对这一挑战的。