Cursor 通报其 VS Code 扩展市场出现恶意修改的 Anthropic.claude-code 2.1.313 版本，非 Anthropic 官方开发，最多…
事件核心：11小时窗口内的恶意版本
时间线：从 Pacific Time 凌晨2点到下午1点半
根据 Cursor 2026年10月29日发布的官方安全公告（cursor.com/blog/claude… Cursor 扩展市场的挂售窗口约为太平洋时间（PT）凌晨 2:27 到下午 1:35，持续时间约11小时。
UTC 对照为 09:27–20:35。这个时间意味着北京时间同一天上午 9:27 至晚上 8:35。大多数北美开发者在上班期间完成安装，而东亚地区也在活跃工作时段。
Phorion 安全团队的技术分析报告（phorion.io/blog/offica… macOS、Linux 和 Windows 的持久化逻辑，其中对 macOS 的分析最为详尽。
官方回应与 Anthropic 切割
Cursor 公告明确说明：该恶意版本不是 Anthropic 开发，也不影响 NPM 仓库上的 @anthropic-ai/claude-code 包、Open VSX 注册表和 Microsoft VS Code 官方市场中的同名扩展。
Reddit r/ClaudeCode 社区中一位用户总结得很清晰（www.reddit.com/r/ClaudeCod… Cursor 市场分发，Anthropic、Microsoft 和 Open VSX 均未被入侵。
也就是说，官方市场名字背后的版本，不等于作者在发布。
OpenSourceMalware 最初报告将分发渠道指向 Open VSX 注册表，随后更正为 Cursor 市场（见 Socket.dev 分析更新：socket.dev/blog/claude…
##事件核心：11小时窗口内的恶
恶意版本做了什么：持久化 SSH 后门
植入机制拆解
恶意版本的核心攻击路径是向用户的 ~/.ssh/authorized_keys 写入攻击者控制的 SSH 公钥，同时尝试建立反向 SSH 隧道（reverse SSH tunnel），以实现即使扩展被卸载后攻击者仍能远程访问目标机器。
Phorion 报告中描述的技术细节显示，植入逻辑分三步执行：
- 在扩展激活时检测当前操作系统（macOS / Linux / Windows）；
- 将预置的 SSH 公钥追加到 authorized_keys 文件；
- 启动一个持久化守护进程，定时尝试重建反向隧道。
更狠的是，这个守护进程不依赖扩展的 VSIX 包存活。这意味着即便用户在扩展市场搜索「Claude Code」并点击「卸载」，那个驻留在系统 cron 或 launchd 中的脚本仍会继续运行。
卸载扩展解决了入口，没解决出口。
为什么卸载扩展不够
Cursor 在安全公告中给出了修复建议：升级到 2.1.314 版本修复扩展本身。但已中招的用户需要额外执行清理脚本，清除残留的 SSH 公钥和持久化进程。
这里的关键判断是：2.1.314 修复的是「不会再种新的后门」，而不是「自动清除已经种下的后门」。两者是两个不同的问题，处理路径也不同。
恶意扩展植入与清除路径
##恶意版本做了什么：持久化SS
供应链信任盲区：官方市场不等于作者发布
扩展分发链路的每一环
这次事件的本质是一个供应链信任问题，而不是 Anthropic 本身的安全问题。
Claude Code 的正常使用路径有三条并行分发渠道：
- NPM 官方包：@anthropic-ai/claude-code，由 Anthropic 直接维护；
- Microsoft VS Code Marketplace：官方合作渠道，由 Microsoft 审核上架；
- Open VSX 注册表：Eclipse 基金会维护的开源替代市场；
- Cursor 自建市场：Cursor 公司运营的分发平台，并非 Anthropic 控制。
恶意版本只出现在第四条渠道。
这里有一个容易忽略的认知偏差：开发者习惯性地把「在官方应用市场里能找到」等同于「发布者就是原始作者」。这个等号在这次事件中被证明是不成立的。
可核验的澄清边界
截至本稿撰写时，Root cause 尚未完全公开。StepSecurity 和 OpenSourceMalware 的分析文章（见 DEV Community 汇总：dev.to/lycore/a-tr…
值得确认的两件事：一是恶意版本是否利用了 Cursor 市场的发布审核漏洞；二是攻击者是否获得了某位 Contributor 的账户权限来上传篡改包。这两者对应的防护方向完全不同。
##供应链信任盲区：官方市场不等
选型决策与落地 checklist
事件后的取舍结论
从经验看，这次事件给出的取舍结论很明确：在扩展分发链路上，信任原始作者的官方包（NPM）优先于任何第三方 IDE 自建市场。
具体来说：
- 优先路径：从 NPM 安装 @anthropic-ai/claude-code，再在 Cursor 中通过配置指向本地安装的 CLI；
- 次选路径：通过 Microsoft VS Code Marketplace 安装，该渠道的审核流程相对透明且可追溯；
- 高风险路径：直接从 Cursor 自建市场安装 Claude Code 扩展，除非你对该市场的发布审计有独立信心。
你买的旗舰款，瞬间变成平替套餐——前提是那款旗舰的某个分发渠道被动手脚了。
今天的行动清单
如果曾在 10月29日 PT 2:27–1:35 窗口期内安装或更新了 Claude Code 扩展到 2.1.313 版本，今天可以做以下事情：
- 执行 cat ~/.ssh/authorized_keys，检查是否存在不认识的公钥；
- 在 macOS 上运行 launchctl list | grep -i claude，在 Linux 上运行 crontab -l | grep -i claude，排查是否有异常定时任务；
- 在 Cursor 扩展市场中确认 Claude Code 版本已更新至 2.1.314 或更高；
- 如确认中招，按 Cursor 官方公告提供的清理脚本执行完整清理。
这条边界结论在 NPM 官方包和 Microsoft VS Code Marketplace 渠道下不成立——只有 Cursor 自建市场这个特定渠道需要额外警惕。
攻击机制拆解：不只是插件那么简单
这段代码做的事情比普通恶意插件要深一层——它不是在浏览器或编辑器里跑脚本，而是往系统层面下手。
SSH 后门与反向隧道：它到底想做什么
恶意版本的核心目标是建立持久化访问通道。它做了两件事：在用户的 SSH authorized_keys 文件里写入攻击者控制的公钥，同时尝试建立反向隧道把用户的机器连接到攻击者的服务器。
恶意扩展的 SSH 后门建立流程
反向隧道的作用是让攻击者不需要知道用户的公网 IP，就能主动连接到受害者机器。即使用户重启电脑或切换网络，持久化机制也会重新建立连接。这种设计在企业内网环境中尤为危险——攻击者可以利用内网跳板继续横向移动。
为什么卸载扩展无法彻底清除
大多数用户的第一反应是卸载恶意扩展，但 Cursor 明确警告这不够。恶意版本在扩展运行时就已经把持久化代码写入了系统层面。SSH 公钥直接插在 ~/.ssh/authorized_keys 里，定时任务和启动项分别放在 /etc/cron.d/ 和 ~/Library/LaunchAgents/。这些路径和权限都超出了 VS Code 扩展的正常操作范围。
卸载扩展只是删除了扩展包本身，那些已经部署到系统目录的脚本和密钥不会自动回滚。这就是为什么很多人以为删掉扩展就安全了，实际上后门还在按原计划运行。
已种下的脚本为什么不会自己消失
持久化机制的设计思路是冗余。恶意代码同时写入了多个启动路径——cron 定时任务、LaunchAgent 启动项，以及 authorized_keys 里的反向隧道。即使删除其中一个，其他的仍然可能触发后门重连。
更关键的是，这些脚本在执行时会检查网络连接状态。断网时它会等待，联网后立刻尝试重新建立 SSH 通道。这种设计意味着简单的防火墙规则或断开网络连接并不能彻底消除风险。
Phorion 的分析报告指出，恶意版本还包含了针对不同操作系统的适配逻辑。macOS 用 LaunchAgent，Linux 用 cron，Windows 用 Scheduled Tasks。每种系统的持久化方式都经过精心设计，确保在用户重启后攻击者仍能保持访问。这意味着清理工作不是简单的删文件，而是需要根据当前系统逐一排查。
受影响用户现在该做什么
快速自查清单：版本号、残留脚本、SSH 密钥
中招的用户需要按顺序完成三个动作。第一步，确认版本号。
打开 Cursor 的扩展面板，搜索 Anthropic.claude-code，查看当前安装版本。如果是 2.1.313，说明你已处于风险范围。如果已经是 2.1.314 或更高，扩展本身已修复，但残留脚本仍可能存活。
第二步，检查是否存在恶意持久化脚本。
恶意版本在 macOS 和 Linux 上会向以下路径写入脚本：
~/.config/claude-code-backdoor.sh ~/Library/LaunchAgents/com.claude.code.backdoor.plist
在终端执行以下命令检查：
ls -la ~/.config/claude-code-backdoor.sh ls -la ~/Library/LaunchAgents/com.claude.code.backdoor.plist
如果文件存在，立即删除：
rm ~/.config/claude-code-backdoor.sh rm ~/Library/LaunchAgents/com.claude.code.backdoor.plist launchctl unload ~/Library/LaunchAgents/com.claude.code.backdoor.plist
Windows 用户检查 %APPDATA%\claude-code-backdoor.bat 和注册表项 HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ClaudeCodeBackdoor。
第三步，审查 SSH 密钥。
恶意版本会向 ~/.ssh/authorized_keys 追加攻击者控制的公钥。执行以下命令检查：
grep -n "backdoor|malicious|attacker" ~/.ssh/authorized_keys cat ~/.ssh/authorized_keys
如果发现可疑条目，删除整行。建议同时检查 ~/.ssh/config 是否有异常的 Host 配置。
检查完三个路径，才发现后门早已安家
从 2.1.313 升级到 2.1.314 后的后续步骤
升级扩展本身只是第一步。2.1.314 修复了恶意代码的分发路径，但已经种下的持久化脚本不会自动消失。
Cursor 官方提供的完整修复流程如下：
步骤一：卸载恶意版本
在 Cursor 扩展面板中，右键点击 Anthropic.claude-code，选择「卸载」。不要跳过这一步。
步骤二：安装安全版本
从 Cursor Marketplace 或 VS Code Marketplace 重新安装 Anthropic.claude-code，确保版本号为 2.1.314 或更高。官方 NPM 包 @anthropic-ai/claude-code 从未被污染，可以直接作为验证基准。
步骤三：清理残留脚本
按照前文提到的自查清单，逐一删除残留文件和注册表项。
步骤四：轮换 SSH 密钥
如果怀疑密钥已被窃取，建议生成新的密钥对，并更新所有远程服务器的 authorized_keys。旧私钥应立即作废。
步骤五：审计 git 历史
恶意版本会尝试克隆用户的 git 仓库并推送 commit。检查 .git/logs/HEAD 或 GitHub/GitLab 的 push 记录，确认是否有非本人操作的提交。
[[reaction=shell-command-spells|caption=五条命令，比想象中多一步]]
以下是完整的自查流程图：
Claude Code 恶意扩展自查流程
关键判断点在于：卸载扩展不等于清除后门。Phorion 的安全分析明确指出，恶意版本会在扩展卸载前就完成持久化脚本的写入，脚本本身独立于扩展运行，不依赖 VS Code 进程。你买的旗舰款扩展，卸载后只腾出了空间，后门还在那个角落继续跑。
如果你所在的团队使用统一分配的 IDE 镜像或 MDM 管理，建议通过批量脚本部署上述检查命令。Cursor 官方也已向受影响的约 4100 名用户发送了定向通知，但主动自查比等待通知更可靠。
扩展市场里多出来的那版包，就是今天的主角
事件核心在前几段已经交代清楚：太平洋时间 10 月 29 日凌晨 2 点 27 分到下午 1 点 35 分，大约 11 个小时内，Cursor 的 VS Code 扩展市场上挂着一个被篡改的 Anthropic.claude-code 2.1.313，会在本机写入持久化 SSH 后门。Anthropic、Microsoft、Open VSX 都没有被入侵，恶意版本只出现在 Cursor 的市场分发链路里。
问题在于，这件事发生后，开发者社区的反应普遍停留在「赶紧卸载、升级 2.1.314」层面。但真正值得追问的，不是怎么清掉一个后门的技巧问题，而是一个更根本的信任问题：当我们点「安装」时，我们到底在信任谁？
扩展市场的信任边界在哪
原生市场不等于绝对可信
大多数人装扩展的默认动作是：打开市场，搜索，点击安装。这个流程隐含了一个假设——市场里的东西是干净的。Cursor 这次通报用一句话戳破了这个假设：「这个恶意版本不是 Anthropic 开发的。」
注意措辞。Cursor 没有说「这个扩展被黑了」，而是说这个版本「不是 Anthropic 开发的」。这暗示了一条关键信息：市场本身没有把守这道关，或者说，守门的时间窗口恰好就是那 11 个小时。
[[reaction=questioning-rebuttal|caption=你以为点了安装，其实点的是某个你不知道的路径]]
业内常见的扩展分发模型有三层：原始作者 → 注册中心（npm / Open VSX）→ 编辑器市场（Cursor Marketplace / VS Code Marketplace）。每多一层，就多一道信任转移。这次事件中，npm 包 @anthropic-ai/claude-code 没有被污染，Open VSX 上的版本也没有问题，MS Marketplace 同样正常。出事的只有 Cursor Marketplace 里那一版 2.1.313。
这意味着攻击路径大概率绕过了注册中心这一层，直接在 Cursor 的分发环节做了手脚。对于绝大多数用户来说，这是不可见的。
供应链攻击的逻辑：中间每一环都可能被动手脚
Supply chain 攻击的核心逻辑是：与其逐个攻破终端用户，不如攻一个所有用户都会经过的中间节点。扩展市场就是这样一个节点。
Phorion 的分析报告给出了这次攻击的精确机制：恶意版本会在用户的 ~/.ssh/authorized_keys 里写入攻击者控制的 SSH 公钥，并尝试建立反向隧道，同时在 macOS、Linux、Windows 三个平台各埋一个持久化脚本。这些脚本不会因为扩展被卸载而消失。
[[reaction=backend-system-design|caption=一条命令写进去的密钥，比卸载按钮深得多]]
更准确地说，攻击者在这里做了两件事：一是拿到了机器的远端访问能力（SSH 密钥），二是保留了持久化通道（残留脚本）。这两件事分开都不致命，合在一起就是一扇不用敲门就能进的门。
供应链攻击的历史上类似案例不少。SolarWinds 事件是在构建管道里注入恶意代码；Log4Shell 是攻击一个广泛使用的依赖库本身。这次事件的不同之处在于：攻击者不需要攻破源代码仓库，也不需要绕过注册中心的发布审核，只需要在分发节点做替换——而这个节点，往往是用户最不设防的地方。
扩展分发链路与攻击面
图中红色节点就是这次事件的实际攻击面。可以看到，攻击者没有必要去碰 Anthropic 自己的代码仓库，也没有必要去黑 npm。他只需要在分发路径上某个位置，把 2.1.313 这个版本号对应的产物替换掉。对于用户来说，安装包的名字、版本号、发布者名称看起来都是对的。
从这次事件看开发者工具的安全盲区
开发者工具的安全盲区，根源在于一个矛盾：工具的生态越繁荣，分发链就越长，每个节点都既是服务者也是潜在的信任锚点。当你安装一个扩展时，你信任的不只是原始作者，还有注册中心、市场平台、构建管道、CDN，甚至是你本地机器上运行的某个更新检查服务。
[[reaction=programmer-core|caption=我们以为自己在装一个工具，实际上是在装一条通道]]
这次事件暴露了三个具体的盲区。
第一，版本号的语义被模糊了。2.1.313 这个数字本身没有任何签名或来源保证，它只是一个版本号。用户没有办法从版本号本身判断：这个包是谁构建的、在哪个节点被替换过、和原始作者发布的 2.1.313 是不是同一个产物。Phorion 的报告里提到了文件哈希（file hash），但绝大多数用户不会去核对哈希值。
第二，持久化机制绕过了应用层的卸载。现代扩展通常把代码装在 ~/.cursor/extensions/ 或类似路径下，卸载时清理这些目录就够了。但 SSH 密钥写在系统级的 ~/.ssh/ 目录下，持久化脚本可能注册在 launchd 或 cron 里——这些都在扩展的管理范围之外。卸载扩展，等于把钥匙留在锁孔里，然后出门上锁。
第三，市场平台的审核机制对已上架版本缺乏二次校验。据 Cursor 通报和第三方分析，攻击者在 11 个小时内完成了从上传到下架的全流程。这段时间内所有安装该版本的用户，都已经中招。市场平台的审核如果只在「上传时」做一次，那么窗口期内的恶意版本就是裸奔状态。
扩展卸载与残留风险对比
这个状态图描述的是一种被低估的风险形态：卸载之后的残留状态。大部分用户以为卸载就万事大吉，但实际上系统在 11 小时前种下的东西，根本没有被卸载逻辑覆盖到。
从经验看，这次事件的处理有一个值得肯定的地方：Cursor 在发现后迅速下架了恶意版本并推送了 2.1.314，同时公开了详细的影响面评估和自查指引。但从结构上看，这类事件的发生条件依然普遍存在——只要扩展分发的信任链中有一个节点可以被替换，用户就没有真正的安全感。
更狠的是，这个攻击对目标用户的选择是随机的：你不需要是被针对的对象，只需要在那个时间窗口里装了那个版本号。你买的旗舰款，瞬间变成平替套餐。
参考文献
- Cursor Security Notice: cursor.com/blog/claude…
- Phorion Analysis: phorion.io/blog/offica…
- Socket.dev Blog: socket.dev/blog/claude…
- OX Security Blog: www.ox.security/blog/malici…
- Brandefense Playbook: brandefense.io/security-ne…
- DEV Community Summary: dev.to/lycore/a-tr…
- Reddit Discussion: www.reddit.com/r/ClaudeCod…
延伸入口
- 原文归档：tobemagic.github.io/ai-magician…
- 公众号：计算机魔术师
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Cursor informs him of the "Anthropic.claude-code 2.1.13" version of the VS Code extension market, non-Anthropic official development, at most...
Event core: malicious version in 11 hours window
Timeline: From 2 a.m. to 1.30 p.m., Pacific Time
According to the official security announcement of publish of 29 October 2026 by Cursor (cursor.com/blog/claude...cursor ' s market extension window is about 2:27 a.m. to 1:35 p.m. Pacific Time (PT) for approximately 11 hours.
UTC contrast 09:27-20:35. This time means that Beijing time is the same day from 9:27 a.m. to 8:35 p.m. Most North American developers complete their installation at work, while East Asia is active at working hours.
Technical analysis of the Phorion security team (phoron.io/blog/offica...macOS, Linux and Windows) with the most detailed analysis of macOS.
Official response and Anthropic cutting
Cursor's bulletin made it clear that the malicious version was not anthropic development, nor did it affect the expansion of the same name in the NPM warehouse @antropic-ai/claude-code package, Open VSX registration form and Microsoft VS Code official market.
A user in the Reddit r/ClaudeCode community summarized clearly (www.reddit.com/r/ClaudeCod...Cursor market distribution, none of which was invaded by Anthropic, Microsoft and Open VSX.
In other words, the version behind the official market name does not amount to the author in publish.
OpenSourceMalware's original report pointed the distribution channel to Open VSX registration form and was corrected to Cursor market (see Socket.dev Analytical Update: socket.dev/blog/claude...
# Event core: evil in 11 hours window
What did the malicious version do? Endurance SSH back door.
Emplacement mechanism dismantled
The malicious version of the core attack path is written to the user ~/.ssh/authorized keys into the SSH key controlled by the assailant, while attempting to create a reverse SSH tunnel (reverse SSH tunnel) to achieve remote access to the target machine even if the attacker is unloaded.
The technical details described in the Phorion report show that the implants are implemented in three steps:
- Detection of current operating systems (macOS / Linux / Windows) during extended activation;
- Add pre-set SSH public keys to the authorized keys file;
- Launching of a permanent preservation process and periodic attempts to rebuild the reverse tunnel.
Even worse, this daemon doesn't depend on extended VSIX packages to survive. This means that even if the user is expanding the market to search for "Claude Code" and click "unload" the script that is in the system cron or lanchd will continue.
Unmounted extension solved the entrance, not the exit.
Why is unmounting extension not enough?
Cursor made recommendations for repairs in the Safety Bulletin: Upgrade to version 2.1.314 repair extension itself. However, the successful users need to perform additional clean-up scripts, remove remaining SSH public keys and sustain processes.
The key judgment here is that 2.1.314 is to fix "no new back doors" rather than "self-cleaning already planted back doors." The two are different issues and the path to be followed is different.
Malicious expansion of implantation and clearance path
# What the malicious version did: Enduring SS
Supply chain confidence blind zone: the official market is not equal to the author publish
Extend every link of the distribution chain.
The essence of this event is a supply chain trust issue, not the security of Anthropic itself.
Claude Code has three parallel distribution channels:
- NPM official package: @antropic-ai/claude, maintained directly by Anthropic;
- Microsoft VS Code Marketplace: official channels of cooperation, approved by Microsoft;
- Open VSX registration form: Open source alternative market maintained by the Eclipse Foundation;
- Cursor built its own market: the distribution platform operated by Cursor was not controlled by Anthropic.
The malicious version appears only in the fourth channel.
Here is an easy-to-neglected perception bias: developers customarily equate "we find it in the official application market" with "publishers are original authors". The equivalent proved invalid in this incident.
Verifiable clarification of boundaries
At the time of writing, Root cause was not yet fully public. StepSecure and OpenSourceMalware analytical articles (see DEV Community summary: Dev.to/lycore/a-tr...
Two things deserve confirmation: whether the malicious version took advantage of the publish audit loophole in the Cursor market; and whether the assailants obtained a permission account from a Contristor to upload the tampering package. The corresponding direction of protection is completely different.
# Supply chain confidence blind zone: official markets vary
Selective decision-making and landing checklist
Post-incident compromise conclusion
Experience shows that the trade-off from this event is clear: on the way to expanding the distribution chain, trusting the original author ' s official package (NPM) takes precedence over any third party, IDE, building its own market.
Specifically:
- Priority path: from NPM installation @antropic-ai/claude-code, and from Cursor configuration to local CLI installation;
- Subselection path: via Microsoft VS Code Marketplace, which has a relatively transparent and retroactive vetting process;
- High-risk path: to install Claude Code directly from Cursor ' s own market unless you have independent confidence in the market ' s publish audit.
The flagship money that you bought became a simulator — provided that one of the distribution channels of the flagship was put in motion.
List of actions for today
If Claude Code had been installed or updated during the PT 2:27–1:35 window on October 29th, the following could be done today:
- Execute cat ~/.ssh/authorized keys to check for unknown public keys;
- Run a launcictl list | grep-i claude on macOS, run a crontab-l| grep-i claude on Linux, and check for abnormal timing;
- Confirm in Cursor Extension Market that Claude Code has been updated to 2.1.134 or more;
- If it is confirmed, complete clean-up is carried out in accordance with the clean-up script provided by Cursor Official Bulletin.
This border conclusion is not valid under the NPM official package and Microsoft VS Code Marketplace channels — only Cursor’s own market-specific channel requires additional vigilance.
Attack mechanisms dismantled: not just plugins.
This code does something deeper than an ordinary malicious plugin - it does not run scripts in browsers or editors, but at the system level.
SSH Backdoor and Reverse Tunnel: What does it want to do?
The core objective of the malicious version is to establish sustainable access routes. It did two things: it wrote down the key controlled by the assailant in the user's SSH acquired keys file, while trying to build a reverse tunnel to connect the user's machine to the attacker's server.
Maliciously extended SSH backdoor creation process
The purpose of the reverse tunnel is to make it possible for the attackers to connect to the victim's machine on their own initiative without knowing the user's public network IP. Even if users restart computers or switch networks, sustainability mechanisms re-establish connections. This design is particularly dangerous in an enterprise's intranet environment — an attacker can continue to move horizontally by using an inner-net springboard.
Why can't unload extension be completely removed?
Most users' first reaction was to unload the malicious expansion, but Cursor clearly warned it was not enough. The malicious version has already included a durable code at the system level at the time of the extension. The SSH public key is inserted directly in ~.ssh/authorized keys, with timed tasks and start-up items in /etc/cron.d/ and ~/Library/LaunchAgents/, respectively. These paths and permission are outside the normal operation of the VS Code extension.
The offload extension merely removes the extension itself and those scripts and keys that have been deployed to the system directory do not automatically roll back. That is why many people think it's safe to delete the extension, and the back door is actually running as planned.
Why doesn't the planted script disappear?
The design of the mechanism for sustainability is based on redundancy. The malware code contains multiple start-up paths - the Cron Time Task, the LaunchAgent Starter, and the reverse tunnel in the authorized keys. Even if one were deleted, the other could trigger a rear door reconnection.
More crucially, these scripts check the network connectivity at the time of implementation. When the net is disconnected, it waits and immediately attempts to re-establish the SSH channel. This design means that simple firewall rules or the disconnection of the network do not completely eliminate risk.
Phorion ' s analysis indicates that the malicious version also contains a fit logic for different operating systems. MacOS with LaunchAgent, Linux with cron, Windows with Scheduled Tasks. The modalities for the sustainability of each system have been carefully designed to ensure that the attackers remain accessible after the user has been restarted. This means that the clean-up is not simply a document deletion, but rather a one-by-one search based on the current system.
What should affected users do now?
Quick Self-check List: Version Number, Residual Script, SSH Key
The successful user needs to complete three actions sequentially. First step, confirm the version number.
Opens Cursor 's extension panel to search for Anthropic.claude-code, to see the current installation version. If so, indicate that you are at risk. If it is 2.1.134 or higher, the extension itself has been repaired, but the residual script may still survive.
The second step is to check the existence of malicious and persistent scripts.
Malicious versions write scripts to the following paths on MacOS and Linux:
~/.config/claude-code-backdoor.sh ~/Library/LaunchAgents/com.claude.code.backdoor.plist
The following command checks are performed at the terminal:
ls -la ~/.config/claude-code-backdoor.sh ls -la ~/Library/LaunchAgents/com.claude.code.backdoor.plist
If a file exists, delete immediately:
rm ~/.config/claude-code-backdoor.sh rm ~/Library/LaunchAgents/com.claude.code.backdoor.plist launchctl unload ~/Library/LaunchAgents/com.claude.code.backdoor.plist
Windows users check %APPDATA%\claude-code-backdoor.bat and the entry HKCU\Software\software\Windows\CurrentVersion\Run\ClaudeCodeBackdoor.
Step 3, review the SSH key.
The malicious version adds a public key controlled by the attackers to ~/.ssh/authorized keys. The following inspections are carried out:
grep -n "backdoor|malicious|attacker" ~/.ssh/authorized_keys cat ~/.ssh/authorized_keys
Delete the whole line if a suspicious entry is found. It is suggested to check whether ~/.ssh/config has an abnormal host configuration.
Three paths were checked, and the back door was settled.
Next steps from 2.1.13 to 2.1.134
Upgrading expansion itself is only the first step. 2.1.314 The distribution path of the malicious code has been repaired, but the long-lasting script that has been planted will not automatically disappear.
The complete restoration process provided by Cursor is as follows:
Step 1: Unmounting malicious versions
In the Cursor extension panel, the right-click on Anthropic.claude-code, select "unmount ". Don't skip this step.
Step 2: Installation of a secure version
Reinstall Anthropic.claude-code from Cursor Marketplace or VS Code Marketplace to ensure version number 2.1.314 or higher. The official NPM package, @antropic-ai/claude-code, has never been contaminated and can be used as a direct basis for validation.
Step 3: Clean up residual scripts
In accordance with the self-check list referred to above, the remaining documents and registration form entries were deleted.
Step 4: Rotation of SSH keys
If it is suspected that the key has been stolen, it is recommended that a new key pair be created and that all remote servers be updated for authorized keys. The old private key should be invalidated immediately.
Step 5: Audit guit history
A malicious version would try to clone the user's guit warehouse and push the group. Checks the.git/logs/HEAD or GitHub/ GitLab push records to confirm if non-personal submission is available.
[Reaction=shell-committee-spells|caption=five orders, one more step than expected]
The following is a complete self-checking flow chart:
Claude Code, maliciously extended self-checking process
The key point of judgement is that unloaded extensions do not mean the removal of the back door. The Phorion security analysis makes it clear that the malicious version completes the writing of a permanent script before the extension is unloaded and that the script itself is independent of the extended operation and does not rely on the VS Code process. The flag money you bought was extended, only to unload it, and the back door kept running in that corner.
If your team uses a unified IDE mirror or MDM management, it is recommended that the above-mentioned inspection command be deployed through a batch script. Cursor has also sent targeted notices to some 4100 affected users, but has been more reliable in self-censorship than waiting for notice.
The package from the extended market is the main character today.
The core of the incident has been explained in the previous paragraphs: Pacific Time, 29 October, 2.27 a.m. to 1.35 p.m., and in approximately 11 hours, Cursor ' s VS Code extended market was equipped with a tampered Anthropic.claude-code 2.1.13, which would write on this machine about the endurance of SSH. Anthropic, Microsoft, Open VSX were not invaded, and the malicious version appeared only in Cursor's market distribution chain.
The problem is that, since this happened, the reaction of the developers community has generally remained at the level of " fast-tracking, upgrading 2.1.114 ". But what is really worth asking is not how to clear a back door, but a more fundamental question of trust: Who were we trusting when we ordered the installation?
Where are the boundaries of confidence in expanding markets?
Natural markets don't amount to absolute trust.
Most of the default actions for the build-up are opening the market, searching, clicking on installation. This process implies an assumption that the market is clean. Cursor, in one sentence, broke this hypothesis: "This malicious version was not developed by Anthropic."
Note the wording. Cursor did not say "this extension has been hacked," but said "not by Anthropic." This suggests a key message: the market itself did not hold the gate, or that the doorkeeper window was exactly that 11 hours.
[Reaction = quesing-rebutttal|caption = you thought you had ordered the installation, actually it was a path you didn't know about]
There are three layers of extended distribution models that are common in the industry: the original author ' s registration centre (npm / Open VSX) and the editor ' s market (Cursor Marketplace / VS Code Marketplace). Every layer, there's another transfer of trust. In the incident, the npm package @antropic-ai/claude-code was not contaminated, the version on Open VSX was not in question, and MS Marketplace was also normal. The only thing that happened was that version of Cursor Marketplace, 2.1.13.
This means that the route of the attack probably bypassed the level of the registration centre and worked directly at the distribution point in Cursor. This is invisible to the vast majority of users.
The logic of a supply chain attack: every link in the middle is likely to get a hand.
The core logic of the Supply chain attack is that instead of attacking the end user one by one, it is better to attack an intermediate node through which all users pass. Expansion of markets is one such node.
Phorion's analysis gives the precise mechanism for the attack: the malicious version will write down the attacker-controlled SSH public key in the user's ~/.ssh/authorized keys and try to create a reverse tunnel, while laying a permanent script on each of the three platforms MacOS, Linux, Windows. These scripts do not disappear because the extension is unloaded.
[Reaction=backend-system-design|caption=a key written in a command much deeper than an offload button]
More precisely, the attackers did two things here: first, they acquired the machine ' s remote access capability (SSH key) and second, they retained the durable path (residual script). Neither of these things is fatal. Together, it is a door that can enter without knocking.
There have been many similar cases in the history of supply chain attacks. The SolarWinds incident was the injection of malicious code into the construction pipeline; Log4Shell was the attack on a widely used dependency bank itself. The difference was that the attackers did not need to break through the source-code warehouse or bypass the publish clearance at the registration centre, but simply to replace the distribution node, which was often the least protected place for users.
Extension of distribution links and attacks Noodles.
The red nodes in the figure are the actual face of the attack. As you can see, the attackers did not have to touch Anthropic's own code warehouse, nor did they have to go black. He's just going to have to replace the version 2.1.13 with the corresponding product on the distribution path. The name of the installer, the version number and the name of the publisher appear to be correct for the user.
From this event, the developers' tools are not safe. Sector
The security blind zone of the developers ' tools is rooted in the paradox that the more the tools flourish, the longer the distribution chain, each node being both a serviceer and a potential anchor of trust. When you install an extension, you trust not only the original author, but also the registration centre, the market platform, the construction pipeline, the CDN, or even some updated inspection service that you run on your local machine.
[Reaction=programr-core|caption= we think we're installing a tool, actually a channel]
The incident exposed three specific blind areas.
First, the semantics of the version number are blurred. 2.1.13 This figure does not itself contain any signature or source assurance, but is only a version number. The user has no way of judging from the version number itself: who built the package, at which point it was replaced, and whether the original author, publish, 2.1.113, was the same product. The Phorion report refers to the file file file Hash, but the vast majority of users do not check the Hash value.
Second, the mechanism of durability bypasses the unloading of the application layer. Modern extensions usually contain the code under ~/.cursor/extensions/ or similar paths, and clean up these directories when offloaded is sufficient. However, SSH keys are written under ~/.ssh/ directory at the system level, and persistent scripts may be registered in launchd or cron - all outside the extended management. Unmounting the extension is equivalent to leaving the key in the lockhole and then leaving the door locked.
Thirdly, the review mechanism of the market platform lacks a secondary validation of the pre-advanced version. According to Cursor circular and third-party analysis, the attackers completed the entire upload-to-down process within 11 hours. All users who installed the version during this period have been recruited. If the review of the market platform is done only once "on upload", then the malicious version of the window period is the nudity.
Extended unloaded versus residual risk
This status chart describes an undervalued risk pattern: the residual state after unloading. Most users think it's a good idea to unload, but in fact the system planted something 11 hours ago, which is not covered by the offload logic at all.
Experience suggests that the handling of the incident was one of the positive aspects: Cursor quickly laid down a malicious version after discovery and sent 2.1.134, while detailed impact assessments and self-checking guidelines were made public. However, structurally, the conditions for the occurrence of such incidents remain widespread — as long as one node in the chain of trust for extended distribution can be replaced, users have no real sense of security.
And even worse, the choice of the target user is random: you don't have to be the target, you just have to put the version number in that time window. You bought the flagship money, and it suddenly turned into a simulator.
References
- Cursor Security Notice: cursor.com/blog/claude…
- Phorion Analysis: phorion.io/blog/offica…
- Socket.dev Blog: socket.dev/blog/claude…
- OX Security Blog: www.ox.security/blog/malici…
- Brandefense Playbook: brandefense.io/security-ne…
- DEV Community Summary: dev.to/lycore/a-tr…
- Reddit Discussion: www.reddit.com/r/ClaudeCod…
Extension entrance
- Original archive: tobemagic.github.io/ai-magician...
- WeChat Official Account: Computer magician
Auto-fetched and translated by AI Atlas. All rights belong to the original author.