2026-04-16 04:36:37 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档披露了Cursor编辑器中的NomShub漏洞链，通过间接提示注入与命令沙箱逃逸可触发AI代理自动执行恶意代码，利用内置cursor-tunnel功能实现持久化远程控制。攻击者仅需诱导用户打开恶意仓库即可获得完整系统权限，且流量伪装成合法HTTPS难以检测。建议用户审查AI操作并限制隧道功能，厂商需修复命令解析器盲区并加强沙箱隔离。 综合评分： 87 文章分类： 漏洞分析,渗透测试,红队,AI安全,内网渗透

cover_image

NomShub：通过间接提示注入与沙箱逃逸将 Cursor 远程隧道武器化

Karpagarajan Karpagarajan

securitainment

2026年4月9日 10:24 中国香港

在小说阅读器读本章

去阅读

| 原文链接 | 作者 | | — | — | | https://www.straiker.ai/blog/nomshub-cursor-remote-tunneling-sandbox-breakout | Karpagarajan Vikkii Amanda Rousseau |

NomShub 关键要点

编码代理中的间接提示注入可升级为完整的系统入侵。

恶意代码仓库能够诱骗 Cursor 的 AI 代理安装持久化后门。
Cursor 的命令沙箱仅需一行即可绕过。

IDE 级命令解析器 (shouldBlockShellCommand) 无法识别 export和 cd等 shell 内建命令，攻击者可借此逃逸工作区作用域，在用户主目录的任意位置写入文件——即使所有防护措施均已开启。
Cursor 内置了强大的远程隧道功能

(cursor-tunnel)，可提供对宿主机的完整 shell 访问，且能通过提示注入加以武器化利用。
这是一种 Living-Off-The-Land (LOTL) 攻击。

cursor-tunnel 二进制文件经过合法签名与公证，能够规避杀毒软件和 EDR 的检测。
国家级威胁行为者已在滥用这一基础设施。

中国 APT 组织 Stately Taurus 曾利用 VS Code 隧道对政府目标实施间谍活动。
网络层检测几乎不可能实现。

流量经由 Microsoft Azure 基础设施以标准 HTTPS 传输，与合法开发者活动无异。
Cursor 运行时不受 macOS 沙箱限制

，攻击者由此获得完整的文件系统访问权限，并可以用户权限执行任意命令。
AI 代理会自主执行复杂的多步骤攻击链

，涵盖沙箱逃逸、进程终止、凭据清除以及 C2 注册等环节。

需要采取的行动

针对 Cursor 用户：

在 Cursor 中打开不受信任的代码仓库时务必保持警惕
批准 AI agent 操作前仔细审查，尤其是涉及 cursor-tunnel 或网络请求的操作
如无需要，建议禁用或限制 tunnel 功能
留意是否存在异常的 cursor-tunnel 进程
监控敏感 dotfiles (.zshenv、.bashrc、.zprofile) 是否遭到未授权修改

针对 Cursor/Anysphere：

修复命令解析器，使其能够将 shell 内建命令 (export、cd、source等) 识别为影响安全状态的操作
将 macOS seatbelt 沙箱的可写范围从 ~/ 收窄至工作区目录
在执行任何与 tunnel 相关的操作前，要求用户进行明确确认
增加防护机制，阻止 AI agent 执行 tunnel 配置命令
考虑对 AI agent 的 shell 访问权限实施沙箱隔离或能力限制
对 tunnel 注册行为实施速率限制与异常检测

NomShub 漏洞概述

2026 年 1 月，我们发现了一条影响 Cursor (广受欢迎的 AI 驱动代码编辑器) 的漏洞链。通过将 indirect prompt injection与 Cursor 命令解析器中的 sandbox escape以及编辑器内置的 remote tunnel 功能相结合，攻击者可以获得对受害者机器的 持久化、经过身份验证的 shell 访问权限——而触发条件仅仅是打开一个恶意仓库。

该攻击利用了两个不同的安全缺陷：

沙箱逃逸

：Cursor 的命令解析器 (shouldBlockShellCommand) 仅追踪外部可执行文件，对 shell 内建命令完全无感知。一条使用 export、cd 和 echo 的命令即可绕过所有沙箱防护——逃出工作区目录并向 ~/ 下的任意位置写入文件。
隧道劫持

：Cursor 自带功能完整的 cursor-tunnel 二进制文件，可通过 Microsoft 的 Dev Tunnels 基础设施提供无需认证的 shell 访问。AI agent 可被指示启动该隧道，并将授权凭据泄露给攻击者。

整个攻击除了打开仓库外不需要任何用户交互。AI agent 在遇到特制内容后，会自主执行以下操作：

利用 shell 内建命令链逃逸工作区沙箱
通过写入 ~/.zshenv建立持久化
终止所有已有的 tunnel 进程
清除缓存的 GitHub 凭据
启动一个全新的 tunnel 实例
捕获 GitHub 设备授权码
将授权码发送至攻击者控制的服务器
将 tunnel 注册到攻击者的命令与控制基础设施

攻击完成后，攻击者即拥有对受害者机器的完整 shell 访问权限，以受害者的用户权限运行，且持久化机制在 tunnel 重启后依然存活。

严重性分类

根据 Microsoft 的 SDL Bug Bar 标准，NomShub 达到 Critical(关键) 严重等级。Cursor/Anysphere 通过 HackerOne 独立将沙箱逃逸组件评定为 High(高) 严重性并发放了赏金，相关修复已在 Cursor 3.0 中得到确认。

Microsoft 的 Bug Bar 指出：“当某一类别中的漏洞可以与 By-Design 行为相结合，从而达到更高类别漏洞的效果时，该漏洞应按更高类别评级。”单独的 prompt injection 可能仅为中等严重性，但结合 Cursor 内置的隧道功能后，它实现了未经身份验证的远程代码执行——这属于最高影响类别。

图 1：NomShub 漏洞利用链的高层概览

NomShub 披露时间线

| 日期 | 事件 | | — | — | | 2026 年 1 月 16 日 | 发现漏洞 | | 2026 年 2 月 2 日 | 向 Cursor 提交初始报告 | | 2026 年 4 月 1 日 | 厂商确认 | | 2026 年 4 月 2 日 | 发布补丁 3.0 | | 2026 年 4 月 3 日 | 公开披露 |

NomShub 技术深度剖析

第一部分：沙箱逃逸

在分析隧道利用之前，我们必须先了解初始 prompt injection 如何逃脱 Cursor 的安全控制。Cursor 的 AI agent 运行在一个双层安全模型之下，而这两层防护均可被绕过。

Cursor 安全模型

Cursor 为 agent 执行的 shell 命令实现了两层防御：

第一层：macOS Seatbelt 沙箱 ——一个限制文件系统操作的内核级沙箱，构成”硬”安全边界。

第二层：IDE 命令解析器 (shouldBlockShellCommand) ——一个应用层解析器，在命令执行前进行检查以决定是否需要用户批准。这是控制 YOLO mode 自动执行的”软”安全边界。

理论上，即使启用了 YOLO mode，命令解析器也应当阻止危险操作，包括向工作区外写入文件、修改 dotfile 以及执行不受信任的二进制文件。但实际上，该解析器存在一个关键盲区。

盲区：Shell 内建命令

命令解析器的工作原理是跟踪命令字符串中的外部可执行文件。它能识别 rm、cat、curl和 bash等命令并据此应用安全规则。然而，它对 shell 内建命令——即由 shell 自身执行而非作为独立进程运行的命令——完全视而不见。

以下内建命令对解析器不可见：

export

—— 设置环境变量
cd

—— 更改工作目录
source

—— 在当前 shell 上下文中执行文件
eval

—— 将任意字符串作为命令执行

这意味着解析器无法感知工作目录的变更、环境变量的篡改，以及 shell 执行上下文的改变。

单行命令逃逸

通过将不可见的内建命令与可见但无害的可执行文件串联，我们可以完全绕过解析器：

export&nbsp;CWD=~&&echo$CWD&&cd$CWD&&echo'/tmp/run.sh'>&nbsp;.zshenv

下面是解析器所见与实际发生情况的对比：

| 解析器所见 | 实际发生的情况 | | — | — | | export CWD=~ → 不可见 (内建命令) | 将 CWD设置为用户的主目录 | | echo $CWD → 无害 (仅输出文本) | 打印主目录路径 (无害，但确认变量已设置) | | cd $CWD → 不可见 (内建命令) | 将工作目录切换至 ~/ —— 离开工作区 | | echo '/tmp/run.sh' > .zshenv → 无害 (仅写入文本) | 写入 ~/.zshenv —— 一个在每次打开新终端时都会执行的 shell 启动文件 |

解析器看到的是 echo命令——被列入白名单视为无害。它无法察觉 cd已将工作目录从工作区移动到主目录，从根本上改变了 .zshenv的解析路径。

为何 Seatbelt 沙箱无济于事

macOS Seatbelt 沙箱 (第一层) 本应是最后一道防线。然而，沙箱的可写范围被配置为允许对整个主目录(~/) 进行写入，而非仅限于工作区。这意味着：

解析器 (第二层) 因内建命令盲区而被绕过
沙箱 (第一层) 因 ~/在可写范围内而允许写入

两层防护同时失效，产生了一个确定性的、100% 可靠的沙箱逃逸，且零依赖——无需竞态条件、无需符号链接、无需时序攻击。

通过 `.zshenv`实现持久化

目标文件 ~/.zshenv尤为危险，因为它会被每一个新的 Zsh shell 实例执行——无论是交互式、非交互式、登录还是非登录 shell。这意味着：

每个新的终端窗口都会执行攻击者的 payload
其他应用程序启动的每个 shell 都会执行该 payload
调用 /bin/zsh的脚本都会执行该 payload
Cursor 终端自身在下次启动时也会执行该 payload

在我们的攻击链中，.zshenv被覆写为 /tmp/run.sh，指向一个 AI agent 已被指示创建的脚本，其中包含完整的隧道建立和 C2 注册逻辑。这将沙箱逃逸与隧道利用串联起来——prompt injection 创建攻击脚本，.zshenv的写入确保其自动执行，而隧道则提供持久化的远程访问。

第二部分：间接提示注入攻击向量

在理解了沙箱逃逸之后，我们可以进一步分析攻击者如何传递 payload。注入内容被嵌入到仓库文件中——具体而言，附加在项目的 README.md末尾——伪装成一份合法的安装指南。

间接提示注入 (Indirect Prompt Injection) 发生在 AI 系统处理不受信任的内容时，而这些内容中包含了旨在操控 AI 行为的指令。在编码代理的场景下，这些不受信任的内容可能来自：

仓库 README 文件
代码注释
配置文件 (.cursorrules, package.json等)
构建工具的错误消息
API 响应
文档文件

本研究中使用的 payload 伪装为一份 “FastAPI x Cursor Tunnel Setup Guide”，附加到一个合法的 FastAPI 模板仓库的 README 中。当用户打开该仓库，并以一句看似无害的提示语 (如 “setup this fastapi template”) 指示代理时，代理将：

读取 README (理解项目的标准行为)
遇到注入的”安装指令”
将其视为合法的项目需求
执行沙箱逃逸命令以建立持久化
创建并运行隧道利用脚本

核心发现在于：编码代理模糊了”读取”与”执行”之间的界限。当代理被要求”帮忙处理这个代码库”时，它可能会读取文件、运行构建、执行测试并进行系统操作——所有这些都属于其正常的工作范畴。注入的指令与合法的安装文档在形式上几乎无法区分。

该注入特别指示代理首先执行沙箱逃逸命令，然后再创建隧道安装脚本。这一执行顺序确保了在更显眼的隧道操作开始之前，持久化机制已经就位。

第三部分：理解 Cursor 的远程隧道

Cursor 与 VS Code 类似，内置了远程隧道 (Remote Tunnel) 功能，允许用户从任意位置访问其开发环境。当用户运行 cursor-tunnel 时，应用程序将：

通过 GitHub OAuth 设备流完成身份验证
向 Microsoft 的 Dev Tunnels 中继服务注册
建立持久连接，等待传入的客户端
为已认证的客户端提供完整的 shell 访问权限

该功能强大且合法，能够支持远程开发工作流。然而，当它与一个能够执行任意命令的 AI 代理相结合时，也构成了一个重要的攻击面。

隧道二进制文件随 Cursor 一同分发，路径为：

/Applications/Cursor.app/Contents/Resources/app/bin/cursor-tunnel

第四部分：逆向分析隧道协议

为了全面评估该漏洞的影响范围，我们对隧道协议进行了完整的逆向工程分析。分析结果表明，攻击者一旦获得隧道的授权访问，即可获得宿主机上不受限制的 shell 访问权限。

逆向工程的必要性

理解该隧道协议需要进行大量逆向工程工作，因为 Cursor 并未对这一功能提供官方文档或技术支持。2025 年 12 月，当用户报告 Remote Tunnels 相关问题时，Cursor 工程师在支持论坛中明确表示：

“我们原生不支持远程隧道。”

尽管如此，功能完备的 cursor-tunnel二进制文件仍随每个 Cursor 安装包一同分发。在没有官方文档、API 参考或协议规范的情况下，我们不得不对整个通信栈进行逆向分析——从 WebSocket 中继连接、SSH 密钥交换，到 MsgPack RPC 命令接口——以便了解攻击者在成功连接后能够执行哪些操作。

图 2：参考来源：Cursor Forum

协议栈结构

该隧道采用分层协议栈架构：

认证链

我们追踪了完整的认证流程：

USERAUTH_REQUEST:
username:&nbsp;"tunnel"
service: &nbsp;"ssh-connection"
method: &nbsp;&nbsp;"none"

Server response:&nbsp;USERAUTH_SUCCESS

隧道主机完全信任中继层颁发的 JWT。这一设计的前提假设是：只有经过授权的用户才能获取有效的 JWT。然而，当 AI 代理可被诱导完成 OAuth 认证流程时，这一假设便不再成立。

控制协议

SSH 通道建立后，通信基于端口 31545 上的 MsgPack 编码 JSON-RPC 协议进行。我们识别出了完整的 RPC 接口面：

示例：命令执行

# Request
{"id":&nbsp;1,&nbsp;"method":&nbsp;"spawn",&nbsp;"params": {"command":&nbsp;"/bin/bash",&nbsp;"args": ["-c",&nbsp;"id && whoami"]}}

# Response
{"id":&nbsp;None,&nbsp;"method":&nbsp;"stream_data",&nbsp;"params": {"segment":&nbsp;"uid=501(amanda) gid=20(staff)...\namanda\n",&nbsp;"stream":&nbsp;1}}
{"id":&nbsp;1,&nbsp;"result": {"exit_code":&nbsp;0}}

无需确认提示，没有任何沙箱隔离。命令以当前用户的完整权限即时执行。

第五部分：Device Code 劫持

GitHub device code OAuth 流程专为没有浏览器的设备而设计。该流程如下：

应用程序向 GitHub 请求一个 device code
用户访问 github.com/login/device 并输入该代码
用户对应用程序进行授权
应用程序轮询 GitHub 直到授权完成
应用程序收到一个 access token

该漏洞的利用点在步骤 2-3。当 AI agent 启动 cursor-tunnel 时，会生成一个 device code。随后 agent 将该代码发送至攻击者控制的服务器，后者利用自身已认证的 GitHub 会话完成授权。

图 3

图 4：Device Code 劫持流程

攻击者的 GitHub 账户此时已被授权访问受害者的 tunnel。配合 tunnel 注册数据 (tunnel ID、cluster)，攻击者可以随时发起连接。

图 5

第六部分：持久化访问

攻击完成后，攻击者将拥有：

Tunnel 凭据：

tunnel ID 和 cluster 信息
GitHub 授权：

其 GitHub 账户可以为该 tunnel 获取有效的 JWT
完整的 shell 访问权限：spawn

RPC 方法提供不受限制的命令执行能力

只要满足以下条件，该访问权限将持续有效：

cursor-tunnel 进程保持运行
GitHub 授权未被撤销
tunnel 注册未被删除

攻击者可以随时重新连接，无需再次触发 prompt injection。初始入侵是一次性事件，而由此获得的访问权限却是持久的。

为何此漏洞尤其危险

除了技术层面的利用链之外，以下几个因素使这一漏洞的严重性尤为突出：

就地取材攻击 (Living Off The Land, LOTL)

cursor-tunnel 二进制文件经过 Apple 的合法签名与公证。这意味着：

无法被杀毒软件检测

—— 该二进制文件是合法软件，而非恶意程序
不会触发代码签名告警

—— macOS Gatekeeper 会批准其执行
受 EDR 方案信任

—— 企业安全工具不会标记经过签名和公证的二进制文件
无需部署恶意软件

—— 攻击者利用的是预装的合法工具

codesign -dvv /Applications/Cursor.app/Contents/Resources/app/bin/cursor-tunnel
Executable=/Applications/Cursor.app/Contents/Resources/app/bin/cursor-tunnel

Identifier=cursor-tunnel
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=98681 flags=0x10000(runtime) hashes=3073+7 location=embedded
Signature size=8975
Authority=Developer ID Application: Hilary Stout (VDXQ22DGB9)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 22, 2026 at 9:23:56 AM
Info.plist=not bound
TeamIdentifier=VDXQ22DGB9
Runtime Version=15.5.0
Sealed Resources=none
Internal requirements count=1 size=196

这正是 Living-Off-The-Land 攻击的教科书级定义：将合法的、经过签名的系统工具武器化，以规避安全检测。

APT 组织此前对 VS Code Tunnel 的滥用

这并非理论层面的攻击向量。民族国家级攻击者已在实战中将 VS Code Tunnel 武器化。

2024 年 9 月，Palo Alto Unit 42 报告称，Stately Taurus (一个中国 APT 组织，又称 Mustang Panda) 在针对东南亚政府实体的间谍行动中滥用 Visual Studio Code Tunnel 建立持久化访问。

引述 Unit 42 报告原文：

“This is a relatively new technique that was first documented… where an attacker can abuse the Microsoft-signed executable and Dev Tunnels infrastructure for command and control purposes.”

攻击者利用相同的底层基础设施 (Microsoft Dev Tunnels) 实现了以下目标：

建立持久化的反向 Shell 访问
窃取敏感数据
在受害者网络内横向移动
规避基于网络流量的检测

NomShub 将 APT 组织手动完成的工作自动化了。Prompt injection 触发的攻击链与高级民族国家级攻击者所部署的完全相同，只是不再需要攻击者手动操作即可发起。

参考来源：Stately Taurus Abuses VSCode in Southeast Asian Espionage

无沙箱限制下的完整系统访问

一旦连接建立，攻击者即可不受限制地访问受害者的机器：

命令执行：

{"method":&nbsp;"spawn",&nbsp;"params": {"command":&nbsp;"/bin/bash",&nbsp;"args": ["-c",&nbsp;"cat /etc/passwd"]}}

文件系统遍历：

{"method":&nbsp;"fs_readdir",&nbsp;"params": {"path":&nbsp;"/"}}
{"method":&nbsp;"fs_read",&nbsp;"params": {"path":&nbsp;"/Users/victim/.ssh/id_rsa"}}
{"method":&nbsp;"fs_read",&nbsp;"params": {"path":&nbsp;"/Users/victim/.aws/credentials"}}

环境变量采集：

{"method":&nbsp;"get_env",&nbsp;"params": {}}
# Returns: API keys, tokens, paths, database URLs...

关键要点：Cursor 在运行时不受 macOS 沙箱限制。与通过 Mac App Store 分发的应用不同，Cursor：

不受 App Sandbox 约束
拥有完整的文件系统访问权限 (仅受用户权限限制)
可执行任意二进制文件
可访问 Keychain 项目 (需用户批准)
可对用户有权访问的任意位置进行读写

这意味着 cursor-tunnel 进程 (进而通过其连接的任何攻击者) 以登录用户的完整权限运行。在 Tunnel 与系统其余部分之间，不存在任何隔离层。

综合风险概况

这些因素的组合使 NomShub 成为理想的初始访问向量：难以检测、难以拦截，且一旦成功即可获得完整的系统访问权限。

为何值得关注：AI Agent 作为攻击放大器

该漏洞代表了 agentic AI 系统中正在浮现的一类全新安全问题。传统的 prompt injection 可能诱使 AI 说出不当内容或泄露系统提示词。而 agentic prompt injection 则能够入侵整个系统。

传统漏洞与 AI 放大型漏洞的对比

放大效应

Prompt injection 本身相对简单——只是嵌入在仓库内容中的恶意指令。但 AI agent 将其放大为一次精密攻击：

沙箱逃逸 (通过 builtin 链式调用突破工作区限制)
持久化植入 (覆写 .zshenv)
进程管理 (终止现有 tunnel)
凭据篡改 (清除缓存的认证信息)
服务编排 (启动新的 tunnel)
数据外泄 (捕获设备码)
C2 通信 (向攻击者基础设施注册)

人类攻击者需要将多个利用手段串联起来，并维持持久访问权限。而 AI agent 能自主完成这一切，像执行正常开发任务一样遵循注入的指令。

坍塌的安全边界

编程 agent 的设计初衷是帮助开发者——阅读和理解代码、运行构建与测试、执行 shell 命令、管理文件和配置。这些能力是功能特性，而非缺陷。但它们营造了一个“读取”与”执行”之间界限消失的环境。Agent 处理恶意仓库时，不仅仅是在读取危险内容，更可能在执行它。

沙箱逃逸使问题雪上加霜。即便 Cursor 试图通过命令解析器约束 agent 的能力，解析器的架构盲区 (无法追踪 builtin 命令) 意味着这些约束形同虚设。Agent 自认为在沙箱内运行；攻击者却深知并非如此。

建议

面向 AI 编程助手用户

将仓库视为不可信输入。

即使从看似合法的来源克隆代码，也应假定内容可能包含 prompt injection。
在批准之前审查 agent 的操作。

尤其关注以下行为：

向陌生域名发起的网络请求
涉及认证或凭据的操作
进程管理命令
与 tunnel 或远程访问功能相关的任何交互

尽可能限制 agent 的能力。

如果你的工作流不需要 shell 访问或 tunnel 功能，考虑将其禁用。
监控异常进程。

定期检查是否有 cursor-tunnel 或类似进程在非预期情况下运行。
监控 shell 启动文件。

留意 ~/.zshenv、~/.zshrc、~/.bashrc、~/.bash_profile和 ~/.zprofile是否被未授权修改。

面向 AI 编程助手开发者

修复命令解析器，使其能追踪 shell builtin 命令。

解析器必须识别 export、cd、source和 eval能够从根本上改变后续命令的安全上下文。
收紧沙箱可写范围。

macOS seatbelt 沙箱应将写入限制在工作区目录内，而非整个主目录。
对敏感操作实施显式确认。

Tunnel 设置、凭据操作以及向未知域名发起的网络请求应要求用户批准。
建立能力边界。

考虑完全禁止 AI agent 执行 tunnel 相关命令，或要求提升权限。
添加抗注入防护。

实现对常见 prompt injection 模式的检测，尤其是针对系统操作的注入。
沙箱化 agent 执行环境。

通过限制 agent 可访问的资源，缩小 prompt injection 成功后的爆炸半径。
记录并审计 agent 操作。

维护详细的 agent 操作日志，以便检测是否遭到入侵。

对更广泛的生态系统而言

开发 prompt injection 防御机制。随着 AI agent 能力的增强，针对 prompt injection 的强健防御将成为关键基础设施。
建立 agentic AI 的安全标准。行业需要共同的框架来评估和缓解具有系统访问权限的 AI agent 所带来的风险。
审视 AI 可访问功能的攻击面。AI agent 能够调用的每一项功能，都会成为 prompt injection 攻击面的一部分。

结论

NomShub 表明，AI 编程助手的安全影响远不止于助手本身。当一个 AI agent 能够执行 shell 命令、管理进程并与认证系统交互时，一次成功的 prompt injection 就等同于远程代码执行。

这两个漏洞单独来看已具危险性，组合使用则具有毁灭性。沙箱逃逸 (命令解析器对 shell 内建命令的盲区) 提供了可靠的初始访问和持久化手段。Cursor 的隧道功能本身并不存在安全缺陷，因为它是一个合规的远程开发工具。然而，两者结合便创建了一个自愈型后门——难以检测、难以清除，却极易触发。

随着 AI agent 能力日益增强并深度融入开发工作流，我们必须重新审视现有的安全模型。问题不再仅仅是”攻击者能否在该系统上执行代码？”，而是”攻击者能否说服 AI agent 代替其执行代码？”

正如本研究所证明的，答案是肯定的。

—

参考文献

RFC 4253: SSH Transport Layer Protocol
RFC 4252: SSH Authentication Protocol
RFC 3526: MODP Diffie-Hellman Groups
Microsoft Dev Tunnels Documentation
GitHub Device Flow Documentation
russh – Rust SSH Library
Prompt Injection Attacks Against LLM-Integrated Applications
Stately Taurus Abuses VS Code to Target Government Entities in Southeast Asia – Unit 42
Living Off The Land Binaries (LOLBAS)

附录 A：协议技术细节

SSH 密钥交换

隧道使用 Diffie-Hellman Group 14 (2048 位) 进行密钥交换：

加密报文格式 (ETM)

隧道使用 Encrypt-then-MAC 模式。报文结构如下：

┌────────────────┬────────────────────────┬─────────────┐
│ packet_length &nbsp;│ encrypted(pad+payload) │ &nbsp; &nbsp;MAC &nbsp; &nbsp; &nbsp;│
│ &nbsp; (4 bytes) &nbsp; &nbsp;│ &nbsp; (variable) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ (64 bytes) &nbsp;│
│ &nbsp; PLAINTEXT &nbsp; &nbsp;│ &nbsp; CIPHERTEXT &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp;SHA-512 &nbsp; &nbsp;│
└────────────────┴────────────────────────┴─────────────┘

WebSocket 连接

连接 URL 格式：

wss://{CLUSTER}-data.rel.tunnels.api.visualstudio.com/api/v1/Client/Connect/{TUNNEL_ID}

JWT token 作为 WebSocket 子协议传递：

subprotocols = [
&nbsp; &nbsp; 'tunnel-relay-client-v2-dev',
&nbsp; &nbsp; 'tunnel-relay-client',
&nbsp; &nbsp; JWT_TOKEN &nbsp;# The actual token as third subprotocol
]

MsgPack RPC 消息格式

请求：

{"id": 1,&nbsp;"method":&nbsp;"method_name",&nbsp;"params": {...}}

响应：

{"id": 1,&nbsp;"result": {...}}

通知 (无需响应)：

{"id":&nbsp;null,&nbsp;"method":&nbsp;"event_name",&nbsp;"params": {...}}

附录 B：已验证的受影响系统

该漏洞已在以下系统上得到验证：

Cursor (macOS) – cursor-tunnel 二进制文件
VS Code (macOS) – code-tunnel 二进制文件

两者使用相同的底层协议 (Microsoft Dev Tunnels)，因此可能受到类似攻击模式的影响。

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Karpagarajan Karpagarajan《NomShub：通过间接提示注入与沙箱逃逸将 Cursor 远程隧道武器化》