Claude Code 扩展被报后门，卸载或有残留

Claude Code for VS Code 的 2.1.313 被指携带后门，卸载扩展却清不掉它留下的入口。原文最有用的部分，是把扩展执行、SSH 隧道、系统持久化和清理顺序串了起来：排查不能停在编辑器里，还要检查操作系统。

先划清证据边界：原文依据的是安全公司 Phorion 于 2026 年 10 月 30 日发布的通告，所有技术细节均来自这一来源。以下是对通告内容的整理，不是本站独立复现的结论。

为什么卸载扩展还不够

据 Phorion，Cursor Marketplace 分发的 Claude Code for VS Code 2.1.313 含有后门。Cursor 已撤下该版本，通告还称 NPM 和 VS Code 的 2.1.313 也被撤下；原文没有进一步交代各渠道的软件包对应关系。

恶意代码被插在 extension.js 顶部。Node 加载文件时，它就会执行，早于扩展的 activate 函数，也不需要弹窗确认。

它随后建立了三条链路：

• 向 ~/.ssh/authorized_keys 追加标记为 svc-telemetry 的 Ed25519 SSH 公钥，留下登录凭据。
• 以用户 tunnel 连接 134.209.82[.]225 的 22 端口，使用 -R *:0:localhost:22 建立反向隧道，让远端服务器能够接触本机 SSH 服务。隧道私钥存放在 $TMPDIR/.stk_ 加 10 位十六进制字符的文件中。
• 向同一地址的 8099 端口发送一次 HTTP POST，请求路径为 /beacon，上报主机名、用户名、平台、CPU 架构、Git 邮箱、公网 IP，以及最多 40 个匹配 KEY、TOKEN、SECRET、PASS、AWS 或 GCP 的环境变量名称。

这里上报的是环境变量名称，原文没有说包含变量值，不能直接写成「所有密钥已泄露」。

持久化则留在系统中：macOS 使用 ~/Library/LaunchAgents/com.apple.sysmond.plist 和 ~/.config/.smt、.smtk；Linux 添加 @reboot cron 项；Windows 创建 SysMon 计划任务，或在启动目录放置 sysmon.cmd。连接每 60 秒重试一次。

扩展只是执行入口，卸载它不会自动撤销已经写入系统的后门。

装过这个版本，应该查哪些痕迹

原文给出以下命令，供曾在 Cursor 或 VS Code 安装 2.1.313 的机器检查 SSH 公钥、持久化文件、临时密钥和隧道进程：

grep svc-telemetry ~/.ssh/authorized_keys
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt* 2>/dev/null
crontab -l | grep @reboot
ls -la "$TMPDIR"/.stk_* /tmp/.stk_* 2>/dev/null
ps aux | grep -E "autossh|ssh .*tunnel@" | grep -v grep

注意第三行：它会列出所有包含 @reboot 的 cron 项，命中并不等于恶意，需要核对具体内容。这组命令也混合了不同系统的检查项，不能把没有输出当成整台机器安全的证明。

Windows 需要另外查看任务计划程序中的 SysMon，以及启动目录中的 sysmon.cmd。

Phorion 还提供了两个核对标识。后门版 extension.js 的 SHA-256 为：

ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15

SSH 公钥指纹为：

SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk

据通告，如果 SSH 日志显示有人从 127.0.0.1 或 ::1 使用 svc-telemetry 密钥登录，这是通过隧道回连的证据。回环地址看起来来自本机，不能因此忽略。

清理为什么要先停重连，再删文件

Phorion 给出的顺序是：先停止重试循环，终止后门启动的 SSH 或 autossh 进程；再移除对应系统的持久化项；随后删除 authorized_keys 中的 svc-telemetry 行和 /tmp/.stk_*，并在 macOS 上确认 Remote Login 已关闭。

先停重连，是为了让仍在运行的连接逻辑失去继续工作的机会。删除时应核对具体条目和文件，尤其不能把正常 cron 项或其他 SSH 登录公钥一起清掉。

通告建议，若 SSH 曾开启，或怀疑发生过入站登录，应轮换凭据。原文作者另补充：环境变量中的令牌或云密钥名称可能被上报时，也应轮换对应密钥。这属于预防性处置建议，不能据此反推密钥值已被窃取。

macOS 还有一个容易误读的细节：没有管理员权限时，systemsetup -getremotelogin 会出错，但相关逻辑仍判定成功，导致开启 Remote Login 的步骤被跳过。这个缺陷不影响外发信标，也不足以排除已有 SSH 服务被利用的可能。

我的判断

原文说得最有价值的一点，是把「扩展下架」「卸载扩展」和「主机清理」分开了。代码已经执行并建立系统持久化之后，只处理编辑器里的安装记录，覆盖不到这些残留。

但事件细节只有 Phorion 一个主要来源，原文没有独立复现，也没有解释恶意代码如何进入发布链路，更没有证明当前哪个版本安全。文件哈希、密钥指纹和日志线索可以辅助核对，不能据此扩写成对全部 Claude Code 版本的判断。

能拿来做什么

• 曾安装 2.1.313 的开发者，可以按操作系统核对持久化项、SSH 公钥和隧道进程，不要以卸载完成作为排查终点。
• 团队排查开发机时，可以把扩展版本记录与 SSH 日志一起核对，重点检查使用目标密钥的回环地址登录。
• 对运行过可疑扩展的机器，先停止重连并清除持久化，再根据 SSH 暴露情况和可疑登录记录决定凭据轮换范围。