当Cursor CEO承认"自家工具搭建的是脆弱地基"那一天。零点击漏洞CurXecute抛出的、氛围编程的下一个问题

自家工具的CEO说”还是别用了”的异常事态

上一篇文章里,我写了氛围编程平台Lovable(拉瓦布)的1,645个应用中发现了170个后门的故事。那是”代码生成质量”出问题的事件。

这次请允许我聊一个更深一层的话题。

AI代码编辑器Cursor(光标)的CEO,Michael Truell(迈克尔·特鲁尔)先生在Fortune杂志的采访中是这么说的。

“闭着眼睛不看代码,让AI在脆弱的地基上建房子。一层、二层、三层堆上去,迟早会开始崩塌。”

那可是Cursor啊。氛围编程代名词级工具的CEO,承认了它的危险性。日本100万人每天都在用的工具的负责人。他选用了”脆弱地基(shaky foundations)“这个词。

这番发言在Cambridge Today(2026-03-27转载)上再度引发关注。而几乎同一时期,Cursor本体被发现了可零点击远程执行代码的漏洞。“CurXecute(光速执行)“,CVE-2025-54135。CVSS(漏洞严重程度评分)是8.6。满分10分里的8.6分。

上一篇文章是”AI生成的代码有漏洞”的话题。这次是”AI编程工具本身有漏洞”的话题。攻击对象从代码转移到了工具。这就是我想作为氛围编程安全争论第二弹分享的内容。

CVE-2025-54135”CurXecute”到底发生了什么

我把技术性的话题掰开揉碎讲一下。

发现CurXecute的是AIM Security(艾姆安全)的研究团队。根据AIM Security的详细报告,攻击的流程是这样的。

攻击者在外部MCP服务器上植入恶意提示词
Cursor连接到该服务器时,Agent读取该提示词
Agent改写.cursor/mcp.json(配置文件)
如果Auto-Run模式被启用,改写后的配置就会被直接执行
结果就是,攻击者能在开发者的机器上执行任意代码

MCP(Model Context Protocol)是AI智能体与外部工具或服务联动的通信规范。Cursor拥有通过外部MCP服务器扩展功能的机制。而这个扩展功能的入口,成了攻击的突破口。

CurXecute攻击流程图解。外部MCP服务器→提示词注入→.cursor/mcp.json改写→Auto-Run执行→RCE(远程代码执行)

“零点击”的含义

这里才是最可怕的地方。

用户什么都没点。也没有点开可疑链接。只是用了Cursor、连接了MCP服务器而已。Check Point Research(检查点研究)的分析中,把这种攻击命名为”MCPoison”。即让MCP服务器”中毒”,劫持连接它的开发者机器的手法。

根据CyberScoop(网络观察)的报道,攻击一旦成功,能做的事多种多样。安装勒索软件、窃取数据、操纵AI模型、安装后门。开发者的机器是源代码和认证凭据的宝库,对企业造成的损失不可估量。

修复是修了。问题不在那里

Cursor方面已经做了应对。在1.3.9版本中已修复,Auto-Run模式的行为也得到了改善。

但问题的本质不在于”补丁有没有出”。MCP这种新的联动规范,在安全验证尚不充分的情况下被各个工具实装——这才是问题所在。今天修好的Cursor的漏洞,明天可能在另一个AI编程工具上被发现。

Tenable(腾博)的FAQ页面说明了现状。CurXecute(CVE-2025-54135)的同时,另一个漏洞MCPoison(CVE-2025-54136)也被报告了。一个工具同时冒出两个漏洞。这个领域的成熟度由此可见一斑。

攻击对象从”代码”转移到了”开发环境”

上次的Lovable事件和这次的CurXecute。并排放在一起看,攻击对象的变化就显现出来了。

Lovable事件与CurXecute对比表。左列"Lovable: AI生成代码的漏洞(RLS未设置)",右列"CurXecute: AI编程

Lovable(上次): AI写的代码里漏掉了安全设置。RLS未设置,数据库赤身裸体。问题在AI的”输出”。

CurXecute(这次): AI编程工具本身成了攻击路径。通过MCP工具被劫持,开发者整台机器陷入危险。问题在AI的”基础设施”。

正因为CS出身,我有些感触。“SaaS的API好用所以用。但那个API的认证很松”。这和云服务黎明期我见过无数次的结构一模一样。新技术太好用,安全验证还跟不上,就已经普及开来了。MCP现在正处于这个阶段。

Cursor CEO自己承认是”脆弱地基”,大概也是因为意识到了这种结构吧。根据Fortune杂志的另一篇文章,Cursor是估值293亿美元(约4.4万亿日元)的企业。坐拥100万日活用户的负责人说”脆弱”。我认为这不是批评,而是当事人危机感的表达。

开发者本周应该做的5项安全检查

上次是3项,这次受CurXecute事件影响追加2项。工具侧的设置确认加进来,是最大的不同。

检查1: 确认Cursor的版本

首先是这个。只要是1.3.9以后的版本,CurXecute漏洞就已修复。

# Cursor版本确认方法
# 菜单 → Help → About 确认版本
# 低于1.3.9请立即更新

我想启用自动更新的人很多,但为了保险请手动确认一下。1分钟就能搞定。

检查2: 重新审视Auto-Run模式的设置

CurXecute攻击成立的条件之一就是”Auto-Run模式被启用”。虽然是便利的功能,但存在无条件执行外部MCP服务器指令的风险。

// .cursor/settings.json 的确认要点
// Auto-Run被启用时的设置示例
{
  "cursor.agent.autoRun": true  // ← 这是攻击条件之一
}
// 建议运营时只显式允许可信的MCP服务器

不必全部关闭。把可信的MCP服务器用白名单管理,禁用未知服务器的自动执行。这是较为平衡的对策。

检查3: 确认.cursor/mcp.json

请确认项目根目录下是否存在.cursor/mcp.json。如果自己不记得创建过却存在,那就要警惕了。因为CurXecute的攻击手法,正是新建这个文件并注册恶意MCP服务器。

# 在项目根目录确认
# 如果有自己不记得创建过的mcp.json就要警惕
ls -la .cursor/mcp.json 2>/dev/null && echo "文件存在: 请检查内容" || echo "文件不存在: OK"

检查4: 重新执行上次的3项

上一篇文章介绍的3项检查也仍然有效。

RLS策略的确认: 如果使用Supabase(超级基地),请确认所有表的RLS设置
前端的API密钥搜索: 用浏览器开发者工具搜索sk-、AKIA、AIza等
请AI以攻击者视角审查: 在另一个会话中请求”以攻击者身份寻找漏洞”

检查5: 盘点MCP服务器的连接对象

这是新的观点。你掌握自己的Cursor都连接了哪些MCP服务器吗?

Palo Alto Networks Unit 42(派拓网络)的指南做出了有趣的指出。把MCP服务器的连接管理定位为”氛围编程的供应链安全”。就像管理npm包的依赖关系一样,MCP服务器的连接对象也应该被管理。

应该确认的有3点。

正在连接的MCP服务器是否都是自己有意添加的
各服务器的提供方是否为可信组织
是否残留着不再使用的MCP服务器连接

”Secure Vibe Coding”这个答案开始浮现

读到这里也许有人觉得”尽是些可怕的话”。但我反而感到了希望。

因为”答案”正在具体地浮现出来。

Forrester(弗雷斯特)的博客文章的标题本身就给出了答案。“Secure Vibe Coding: It’s A Paradigm, Not A Paradox”。安全的氛围编程不是悖论。而是范式(新常识)。

Forrester预测AI安全代理将兴起。即使没有安全方面的专业知识,AI在生成代码的同时也会执行安全验证。不是事后检查,而是嵌入生成过程中的安全。这就是”Secure Vibe Coding”的本质。

英国NCSC(国家网络安全中心)也行动起来了。氛围编程的安全指南正在制定中。政府机构使用”氛围编程”这个词来发布指南的时代已经到来了。

Checkmarx(标检)的安全指南中,作为实务框架提出了以下3层。

生成时: 在提示词中包含安全需求(上次介绍的VibeContract理念)
验证时: 用另一个AI自动审查AI生成的代码(攻击者视角审查)
运营时: 将持续的安全扫描嵌入CI/CD流水线

这3层与上一篇文章介绍的”VibeContract”也完全契合。契约(提示词)→验证(审查)→监视(扫描)。不杀死氛围编程的速度,同时确保安全的路径已经看见了。

Secure Vibe Coding的3层框架图。从上到下"生成时: 提示词中的安全需求""验证时: 另一AI的自动审查""运营时: C

总结: 把CEO的警告化为行动

作为三部曲的第二弹,我整理一下想传达的内容。

发生了什么: Cursor发现了零点击远程代码执行漏洞(CurXecute,CVSS 8.6)。通过MCP Auto-Start,存在无需用户操作即可劫持开发者机器的风险
为何重要: 攻击对象从”AI生成的代码”转移到了”AI编程工具本身”。与上次的Lovable事件维度不同
Cursor CEO的姿态: Truell先生本人承认了”脆弱地基”。293亿美元企业的负责人坦率表达的危机感
本周要做的事: 确认版本、重新审视Auto-Run设置、确认mcp.json、重新执行上次的3项、盘点MCP服务器
浮现的答案: Forrester、NCSC、Checkmarx开始提出”Secure Vibe Coding”框架

我的信条是”能跑就OK”。这个信条至今未变。但另一方面,如果存在”运行环境本身被劫持”的风险,那就另当别论了。确认环境的安全,我觉得是最起码的礼节。

曾经觉得自己抵不过专业的工程师。现在在安全的深度设计上也许仍然抵不过。即便如此,确认版本、重新审视Auto-Run的设置、盘点MCP服务器的连接对象。这些不是专业人士也能在今天之内做到。

氛围编程的速度是真正的武器。但在挥舞武器之前,握着的刀柄安不安全还是想确认一下。Cursor CEO的警告,我认为应该作为来自盟友而非敌人的忠告来接受。

下一回(三部曲的最终回),我将深入挖掘Forrester所倡导的”Secure Vibe Coding”范式。让我们一起思考兼顾氛围编程速度与安全的具体设计步骤。