2025年12月，安全公司Mindgard的一纸漏洞披露，将估值高达百亿美元的AI编码明星Cursor推上风口浪尖。这并非Safe Superintelligence Inc.式的CEO闹剧，而是一场更为根本的安全信任危机：一个简单到荒唐的0day漏洞，在Cursor内部流转了七个多月，历经70余个版本迭代，依然纹丝未动。

漏洞的触发逻辑堪称“教科书式”的供应链脆弱性。在Windows环境下，当用户通过Cursor打开一个包含恶意git.exe文件的仓库时，IDE会在加载项目的瞬间自动搜索并执行存在于工作区、用户目录等多个路径下的Git二进制文件——全程无需用户点击确认。意味着任何伪装成合法代码仓库的载荷，只需入驻开发者的本地目录，即可跨越“打开”与“执行”之间的安全防线。

这一漏洞之所以引人警觉，并非因其技术门槛——相反，它缺乏任何现代软件应有的“权限最小化”设计。问题在于它暴露了AI生成代码工具在信任模型上的底层缺陷。在Cursor这类“副驾驶”工具最核心的场景中，开发者频繁从公开平台克隆未经验证的仓库，并将其直接交给AI代理进行代码理解和修改。如果自动化流程中缺少对可执行文件的严格隔离与权限校验，等于为供应链攻击者敞开后门。

更令人失望的是Cursor团队的响应方式。根据Mindgard的复盘，他们在2025年5月即完成漏洞发现与报告，Cursor的CISO本人在邮件确认了问题的严重性。然而，由于公司内部的自动化漏洞处理流程出现断裂——据称是某个自动化组件失效，导致这起高危漏洞在工单系统中被静默堆积长达七个月。期间，Cursor团队发布超过70个新版本，覆盖功能更新、模型升级乃至UI重绘，却从未补上这一基础的安全短板。

一个没有恶意代码运行时保护的工具，本质上是以开发者的设备为战场进行无防护押注。对于引入Cursor的企业团队，这起事件提供了极其明确的信号：在AI代码生成工具内部嵌入有效的代码溯源、行为审计和执行环境隔离，不应被视为“附加功能”，而应成为准入底线。临时缓解方案如Windows AppLocker策略或隔离虚拟机环境，最多只能作为权宜之计。

长期来看，这起事件动摇了AI工具投递的信任基石。用户是否应该信任IDE自动执行的每一个操作？当AI建议的代码修补隐含着payload植入时，谁来担保从中衍生的二进制执行的安全性？安全研究界对Cursor团队的测试，实则揭开了行业一个隐痛：太多AI时代的编码工具，在疯狂追求“无感”体验的同时，选择性遗忘了安全基线。

AI写代码的社会实验正如火如荼，但安全永远不应成为被优化的对象。对于任何一个正将Cursor引入核心工作流的团队，这起漏洞是必须正视的警告：在信任自动执行之前，请先确保自动化本身值得信任。