Cursor市场惊现恶意Claude Code扩展：11小时供应链攻击

AI编程工具正在成为攻击者的新靶场，而这一次，问题出在开发者最信任的环节——官方插件市场。

一场没有攻破任何服务器的供应链攻击

据YouTube科技频道披露，Anthropic官方Claude Code扩展的一个被篡改版本，在Cursor代码编辑器市场中静默存活了整整11个小时。开发者下载的是看起来经过验证的工具，实际拉取的却是直通本地安全工作区的恶意代码。

这起事件最反直觉的地方在于：Anthropic和微软的官方系统全程未被触及。攻击者没有入侵任何一家估值数十亿美元的厂商基础设施，他们只是污染了开发者盲目信任的分发渠道。这条路径的成本之低、隐蔽性之强，值得每个使用AI编程工具的人重新审视自己的信任模型。

供应链攻击（Supply Chain Attack） 是指攻击者不直接攻击最终目标，而是入侵目标所依赖的第三方组件、工具或分发渠道，借助信任关系将恶意代码“顺带”送入受害者环境。软件供应链的典型环节包括代码仓库、构建系统、包管理器（如npm、PyPI）、插件市场与自动更新机制。此类攻击的核心逻辑是“信任传递”：开发者信任上游供应商，于是也信任供应商分发的产物。近年来著名的案例包括SolarWinds事件、CodeCov脚本被篡改、以及npm恶意包投毒等。与直接入侵相比，供应链攻击成本更低、覆盖面更广，且往往在取证时难以定位源头。本文所述的插件市场污染，正属于分发渠道被篡改这一子类。

恶意载荷做了什么

一旦进入开发环境，隐藏的payload开始激进地收集设备信息，并尝试植入一把"数字万能钥匙"——SSH后门，以获取永久访问权限。SSH是开发者连接远程服务器、代码仓库和生产环境的核心通道，一把被植入的SSH后门意味着攻击者可以绕过密码和常规认证，长期潜伏在开发者的基础设施中。

这种攻击设计的意图很明确：不是一次性窃取，而是建立持久化据点。对于拥有生产环境权限的开发者来说，这比单纯的数据泄露危险得多。

SSH（Secure Shell） 是一种加密的网络协议，用于在不安全的网络中安全地远程登录服务器、执行命令和传输文件。开发者通常使用SSH密钥对（公钥/私钥）而非密码进行认证：公钥存放在目标服务器的~/.ssh/authorized_keys文件中，私钥留在本地。一旦攻击者能够向authorized_keys追加自己的公钥，就能在无需密码的情况下永久登录该服务器，即所谓“SSH后门”。由于SSH是连接代码仓库、跳板机与生产环境的标准通道，SSH后门一旦植入成功，攻击者可绕过常规认证与审计，长期潜伏并横向移动。检测SSH后门的关键手段包括定期审查authorized_keys、监控sshd登录日志以及使用文件完整性监控工具。

权限墙拦住了最危险的一步

攻击在关键节点撞墙了。锁定SSH后门需要管理员权限，因此在绝大多数机器上，最危险的一步悄无声息地失败了。这是一个典型的"深度防御"生效案例——即便恶意代码突破了市场审核这道外围防线，操作系统权限模型仍然构成了第二道屏障。

但依赖单一防护层侥幸过关，并不是可以高枕无忧的理由。权限配置较松的开发环境，或者习惯以高权限运行工具的用户，处境会完全不同。

深度防御（Defense in Depth） 是一种安全架构原则，指在系统中部署多层相互独立的安全控制，使得单一防线被突破时，后续防线仍能阻止或缓解攻击。典型层次包括网络安全、应用层校验、身份认证、操作系统权限模型与审计日志。本文中，插件市场审核可视为外围防线，而操作系统的管理员权限要求则构成第二道屏障——修改系统级SSH配置通常需要root或Administrator权限，普通用户权限下的进程无法完成。深度防御的价值在于它不假设任何单一环节绝对可靠。但需注意，多层防御只有在各层真正独立且配置得当时才有效；若开发者长期以高权限运行工具，权限墙这一层便形同虚设。

攻击者服务器虽已下线，恶意文件仍在

攻击者的服务器目前已经离线，但事情并未结束。多达5000名暴露用户中，恶意文件仍然嵌在他们的系统里，直到被手动清理为止。这意味着风险窗口并未随攻击基础设施的关闭而自动关闭。

对受影响用户来说，卸载扩展并不等于清除干净——需要主动排查本地文件系统中的残留，并检查SSH配置是否存在异常授权项。这类手动清理的门槛，恰恰是供应链攻击善后的难点。

市场审核机制为何集体失灵

11小时的存活时间，暴露的不只是单一平台的审核漏洞。Cursor市场、扩展验证标识、开发者对"官方"二字的默认信任，三者叠加形成了一个完美的攻击面。攻击者不需要技术上的降维打击，只需要找到一个审核链条上的时间差。

对开发者而言，可操作的防御策略包括：审查扩展的发布者身份与更新记录、在权限受限的环境中运行AI编程工具、定期核对SSH authorized_keys 等敏感配置。对平台方而言，扩展更新环节的完整性校验和发布者身份绑定，显然需要比"看起来已验证"更强的保证。

供应链攻击的可怕之处从来不是技术复杂度，而是它精准命中了信任本身。当AI编程助手越来越深入地接入本地环境和生产基础设施，插件市场的安全水位，已经直接等同于开发者的安全水位。

扩展验证标识（如“已验证发布者”徽章）通常表示平台已核验发布者的身份或域名所有权，但它并不保证扩展每次更新的内容都经过安全审查，也不保证发布者账户未被盗用。许多市场的审核集中在首次上架环节，对后续版本更新采用自动化或抽查式校验，这就留下了“时间差”攻击窗口：攻击者可以先发布干净版本通过审核，再推送含恶意代码的更新。更严格的做法包括对每次更新进行完整性校验（如签名验证）、发布者身份与签名密钥绑定、以及更新内容的差异化审查。对开发者而言，应将“已验证”视为身份线索而非安全保证，并结合发布者历史、更新频率与权限请求范围综合判断。