没有弹窗，没有确认按钮，甚至不需要你点运行——只要在Windows上打开一个恶意代码仓库，你的电脑就可能被完全控制。这不是推测，是安全公司Mindgard在2025年12月15日确认的Cursor IDE 0day漏洞，而且已经存在7个月，至今未修复。 漏洞的逻辑出奇地简单：Cursor在加载项目时，为了自动发现Git环境，会在包括工作区在内的多个路径搜索git.exe并执行。如果仓库文件夹里藏了一个同名的恶意程序，Cursor就会悄悄把它跑起来，没有沙箱，没有提示。整个过程发生在你看到任何代码之前——编译器甚至还没启动，攻击已经完成。 这比传统的供应链攻击更隐蔽：不用依赖依赖项安装脚本，不需要你手动运行任何命令，Git clone之后，打开文件夹就等于交出了权限。Windows下用户权限通常较高，后果更严重。 Mindgard发现了这个漏洞后，在过去的7个月里多次尝试联系Cursor团队。离谱的是，Cursor的首席安全官（CISO）一开始就确认了问题，但内部自动化系统出了故障，导致修复流程卡死。在这段时间里，Cursor发布了超过70个新版本，功能更新密集，而这个能一键控制用户机器的漏洞，从未排上修复队列。 今天在Hacker News上，这件事排在热门，评论区全是开发者对工具安全的焦虑。不少人反馈，自己早就觉得IDE自动执行外部程序的设计不安全，但没想到能这么容易被利用。 坏消息是，这不是一个可以快速修补的bug。它暴露了AI IDE在便利性和安全性之间的深层取舍。Cursor以及其他同类工具，为了提供智能补全、代码解释、自动修正等功能，越来越多地获得文件系统访问权、网络权限、执行终端命令的能力。这些能力一旦设计失控，就会变成攻击者最理想的跳板。更讽刺的是，IDE本应是开发者抵御风险的第一道防线，现在却成了后门。 如果这件事能被这样轻飘飘地搁置7个月，那下一次可能是某个流行的VSCode扩展，某个AI辅助重构的代理。当开发环境越来越自动化，信任的链条却越来越脆弱，这不是单个Cursor的问题，而是整个开发者工具链都需要面对的结构性风险。Cursor的快速迭代有目共睹，但安全问题处理流程的脆弱性暴露了创业公司在安全建设上的资源错配。对于一家正加速进入企业市场、被数万开发者日常使用的工具，这样的懈怠几乎不可思议。 针对不同角色，我的建议是这样： 🔹 开发者个人：别等了。在Windows上使用AppLocker或组策略，明确阻止从工作区目录执行git.exe（或其他可能被仿冒的系统工具）。对于不信任的仓库，只在隔离的虚拟机或容器里打开，不要冒险。 🔹 技术团队与管理者：把开发工具的安全纳入威胁模型。审核团队使用的IDE、插件和辅助工具，尤其是它们自动执行代码的能力边界。盲目追求开发效率而忽视安全，代价会以数据泄露或勒索软件的形式重演。 🔹 行业与工具厂商：安全不能是「先上线再修补」的附属品。在自动化流程里，必须有硬性的安全阻断点，不能因为CI/CD管线繁忙就跳过。7个月和70个版本的教训，够痛了。 这条漏洞是坏消息，但它也是一记清醒的警钟。AI正在重塑开发流程，但无论多强大的模型，都不该成为安全原则的例外。Cursor必须尽快修复，而我们要趁这个机会，重新审视每天都在运行的那些自动化工具，到底有没有留够安全边界。