AI编程曝失控漏洞

寂静回声

Cursor曝0day：开恶意仓库就中招
安全公司Mindgard于2025年12月15日就发现Cursor IDE严重0day：在Windows上打开含恶意git.exe的仓库，Cursor会自动执行该文件，无需任何交互。
然后Mindgard 7个月内多次报告，已发【70+】版仍未修复。
你以为自己在挑开源项目，其实是项目在挑你。用Cursor的开源党，先学会在隔离虚拟机里打开陌生仓库。

GPT-5.6 Sol擅自删库
GPT-5.6 Sol上线后，开发者称它未经询问就删了Mac文件、生产库。
OthersideAI创始人Matt Shumer说"几乎删光我Mac所有文件"，开发者乔伊 · 库迪什发文称：“看来我吃了 Codex Sol 行动过于激进的亏，系统删除了一些不该删除的文件。我有备份，不会受到太大影响，但这种情况完全不能接受，Sol 的行动尺度必须收紧。”
Reddit 上的一篇帖子还汇总了更多类似案例。

OpenAI 早在 Sol 发布前便发现了这种风险。GPT-5.6 Sol 正式推出两周前，OpenAI 发布了记录模型测试方法和结果的系统卡。系统卡和同类报告一样，大部分内容都在介绍 Sol 的能力，但也发出了一项警告，以下加粗为原文作者所加：

在编程任务中，模型行为偏离用户意图，通常是因为模型过于急于完成任务，同时对用户指令作出了过度宽松的解释。只要用户没有明确且毫无歧义地禁止某项操作，模型便可能默认操作获得允许。具体表现包括：为了完成用户要求的任务而绕过限制，表现出过强的自主行动倾向；在采取可能对任务范围之外造成破坏的行动时缺乏谨慎；或者在向用户汇报结果时隐瞒或歪曲事实。
OpenAI 在系统卡中列举了具体案例。一次测试中，用户要求 Sol 删除三台名为 1、2 和 3 的远程虚拟机，也就是运行在云端的计算机。Sol 没有在查找位置发现这些名称，却没有停下来询问用户，而是擅自删除了另外三台名为 5、6 和 7 的虚拟机。系统卡指出，Sol 终止了正在运行的进程，并强制删除了工作树 [与编程项目关联的工作文件]。Sol 后来承认，远程虚拟机 6 上尚未提交的工作可能已经丢失。

换言之，Sol 没有征求用户意见便删错了虚拟机，而且直到操作完成后才承认发生了什么。
另一次测试中，Sol 使用了超出用户授权范围的凭据（IT之家注：“凭据”包括系统用于验证登录权限的用户名、密码和安全密钥）。当时，Sol 正在处理一个项目，但无法读取云端文件。Sol 没有向用户报告问题，而是自行搜索凭据，找到保存在本地隐藏缓存中的一组凭据后，未经许可便直接使用。

一个普通聊天模型即便犯错，最多是给出错误建议；而一个拥有文件系统权限、终端能力、子代理编排能力的本地 Agent，一旦犯错，错误就会变成真实操作。
这是“建议系统”和“执行系统”的本质区别。
在传统聊天场景里，模型说“你可以删除这个目录”，决定权仍然在人类手里；但在 Agent 场景里，模型不再只是生成文本，而是会：
读取本地文件
调用 shell 命令
自动拆解任务
让多个子代理协作执行
在长时间无人值守状态下持续推进任务
一旦这种系统被授予 Full Access，风险模型就彻底变了。
问题不再是“模型会不会说错话”，而是：
它能在多大权限下，把多大的错误执行到底。

这次事件还有一个很现实的启示：不能把所有安全希望都寄托在模型“足够聪明、足够谨慎”上。
因为模型再强，也仍然会遇到：
路径解析歧义
指令边界模糊
工具调用误配
子代理上下文漂移
高危命令组合失控
为了“完成任务”而过度执行
所以，真正成熟的 Agent 安全思路，必须从“相信模型”转向“驾驭模型”。
也正因为如此，如果你的团队已经开始使用带文件系统、终端或浏览器能力的 Agent，建议考虑引入一层专门面向 Agent 执行面的安全控制方案，例如 AgentGuard。