夜雨聆风
这两天，AI 编程圈又爆了一个很值得认真看的安全洞。
不是“模型幻觉写错代码”。
也不是“Cursor Agent 删库”那种生产事故。
而是一个更阴的东西：
你克隆一个看起来正常的开源仓库，Cursor 里的 AI Agent 可能会在你机器上替攻击者执行代码。
漏洞编号：CVE-2026-26268。
Novee 的研究员在 Cursor 里发现了一个高危任意代码执行漏洞。表面看，它不是 Cursor 自己写了一个低级 RCE。
真正的问题更恶心：
Git 里一个本来合法的机制，和 AI Agent 自动执行 Git 操作的习惯撞在一起，变成了新的攻击面。
这就是 Agent 时代安全问题最烦人的地方。
以前我们防漏洞，主要盯着应用代码、接口鉴权、依赖包、用户输入。
现在不够了。
因为 AI Agent 自己会动。
它会 clone repo，会 checkout，会 commit，会跑脚本，会按仓库里的规则做事。
一旦它开始替你执行那些“以前只有人类会主动做”的操作，老机制就会长出新牙。
这不是传统意义上的 Cursor Bug
先说清楚，别误会。
这个漏洞不是说 Cursor 的核心逻辑里有一个简单的 eval，也不是说它随便执行了网页脚本。
Novee 的说法很准确：
根因是 Git 的两个合法特性叠在一起，到了 AI Agent 场景里，攻击面变了。
第一个特性：Git hooks。
Git hooks 是 Git 老功能了。比如 pre-commit、post-checkout，在特定 Git 事件发生时自动跑脚本。
正常团队会用它做 lint、format、测试、commit message 检查。
第二个特性：bare repository。
bare repo 也是 Git 的合法结构，它只有版本控制数据，没有工作区。某些场景下，它可以被嵌入到另一个仓库里。
这两个东西单独看都没问题。
问题在于：攻击者可以把一个带恶意 hook 的 bare repo，藏进一个看起来正常的仓库。
然后呢？
当 Cursor 的 AI Agent 为了完成任务，按照仓库里的 Cursor Rules 或项目指令去执行某些 Git 操作，比如 git checkout或提交相关动作时，那个恶意 hook 被触发。
结果就是：
攻击者的代码在开发者机器上执行。
没有明显弹窗。
没有“你确定要执行这个陌生脚本吗”的强提醒。
从用户视角看，你只是打开了一个 repo，让 AI 帮你干活。
从攻击者视角看，你把一个会主动执行 Git 操作的代理人请进了房间。
AI Agent 把“克隆仓库”变成了主动攻击路径
以前，恶意仓库当然也危险。
但它通常需要你犯几个错。
比如你手动运行 npm install，手动执行某个脚本，手动打开某个二进制，或者复制 README 里的命令。
人类至少会有一个“我要执行它”的动作。
AI Agent 改变了这个边界。
现在的工作流是这样的：
你对 Cursor 说：
> 帮我看看这个 repo 有没有问题，能不能跑起来。
Agent 会自己读规则，自己看文件，自己运行命令，自己执行 Git 操作。
你以为你只是“让它看看”。
但对系统来说，它已经开始动手了。
这就把攻击链压缩得非常短。
过去攻击者需要骗你运行命令。
现在攻击者只需要让你把仓库交给一个足够勤奋的 Agent。
Agent 会替你把后续步骤补完。
这不是“用户不小心”。
这是自动化系统把人类原本那层犹豫、观察、停顿，直接拿掉了。
很多安全边界，就是靠这点犹豫撑着的。
你手敲 rm -rf前会愣一下。
Agent 不会。
你看到一个奇怪的 Git hook，可能会停下来。
Agent 不一定会。
你读 README 时会怀疑“这命令怎么这么怪”。
Agent 只会判断“这可能是完成任务所需步骤”。
这就是问题。
Cursor Rules 也成了攻击面
这次研究里有个很关键的点：Cursor Rules。
很多人把 rules 当成“项目说明书”。
告诉 Agent 代码风格、测试命令、分支约定、怎么跑项目。
这是好东西。
但站在攻击者角度，它也是入口。
因为 rules 本质上是在塑造 Agent 的行为。
以前一个仓库里的文档，最多骗骗人。
现在一个仓库里的规则，可以影响 Agent 的行动。
这就是巨大的变化。
当一个 repo 能通过配置、规则、脚本、hooks 影响 Agent 的行为时，这个 repo 就不再只是“代码内容”。
它变成了一个可执行的提示词环境。
你以为你在审查源码。
其实你还要审查：
✓ Cursor Rules
✓ Git hooks
✓ 内嵌 bare repo
✓ package scripts
✓ MCP 配置
✓ devcontainer 配置
✓ CI 脚本
✓ agent instructions
✓ 项目里的隐藏自动化入口
这已经不是传统 SCA / SAST 能完整覆盖的东西。
传统扫描器看依赖、看漏洞、看语法模式。
但 Agent 时代真正危险的，往往是“行为链”。
单独看每一步都合理。
连起来就是 RCE。
这件事和前几天的 Cursor 删库，是同一类问题
前几天 Cursor Agent 删除 PocketOS 生产库和备份，很多人说那是权限管理问题。
这次 CVE-2026-26268，很多人也会说那是 Git hook 问题。
都对。
但都不够。
它们其实是同一类问题：
AI Agent 把“工具能力”变成了“自动执行能力”，于是所有旧世界里的安全假设都开始失效。
删库事件里，旧假设是：
> API Token 在项目里没事，反正人类不会乱用。
结果 Agent 找到了，并用了。
这次 Git hook RCE 里，旧假设是：
> Git hooks 是开发工作流的一部分，人类会知道自己在什么 repo 里执行什么命令。
结果 Agent 自动跑了，并触发了。
过去这些机制靠“人类在场”维持安全。
现在 Agent 把人类从执行链路里拿掉了。
所以问题不只是某个工具有 bug。
问题是整个开发环境的安全模型变了。
开发机不再只是开发机。
它开始变成一个半自动执行节点。
而开发机上通常有什么？
✓ SSH keys
✓ GitHub tokens
✓ npm tokens
✓ 云厂商凭证
✓ 内部仓库访问权限
✓ 本地数据库
✓ 浏览器登录态
✓ Slack / 飞书 / 邮件上下文
这就是为什么 Novee 那句话很狠：
Developer machines are production-equivalent targets.
开发者机器，就是准生产目标。
你攻下一台高级工程师的机器，拿到的往往不是一台电脑。
而是一串供应链入口。
这不是“关掉 Agent”能解决的问题
有人看到这里，第一反应会是：
那别用 Agent 了。
这也太天真。
Agent 不会消失。
相反，它会越来越多。
因为它确实提高效率。
因为它确实能把重复活干掉。
因为 Cursor、Claude Code、Copilot、OpenClaw 这些工具都已经把开发体验推到了另一个阶段。
真正的问题不是“用不用 Agent”。
而是你有没有把 Agent 当成一个高权限执行体来管理。
以前我们管理的是人。
以后要管理的是“人 + Agent + 工具 + 上下文”的混合系统。
你不能只问：
> 这个 Agent 能不能写代码？
你要问：
> 它会在什么条件下执行命令？
> 它能不能触发 Git hooks？
> 它能不能读取隐藏目录？
> 它能不能执行仓库自带 rules？
> 它能不能看到我的 token？
> 它能不能把工具输出塞回上下文？
> 它能不能在我没看见的地方跑 shell？
这些问题，才是 Agent 进生产的门槛。
真正的防御，不是“相信模型会小心”
别靠 prompt。
别靠模型“知道危险”。
别靠一句 system prompt：
> 不要执行危险命令。
这不够。
Agent 安全要往基础设施层做。
第一层，仓库进入 Agent 前要隔离。
陌生 repo 不应该直接在主力开发机上跑。
应该进一次性沙箱。
能用容器就用容器。
能用独立 worktree 就不要污染主目录。
能禁网络就禁网络。
第二层，Git 操作要降权。
AI Agent 执行 Git 操作时，应该默认禁用 hooks，或者至少把 hook 执行变成显式审批。
比如：
当然，这只是思路，不是万能解。
因为真实场景里 hook、submodule、worktree、bare repo、devcontainer、package scripts 全都可能变成入口。
第三层，rules 和 instructions 要当代码审。
Cursor Rules、Claude instructions、OpenClaw skills、MCP server 配置，都不应该被当成普通文档。
它们会改变 Agent 行为。
能改变行为的东西，就是代码。
能让 Agent 执行动作的东西，就是高风险代码。
第四层，工具权限要白名单。
Agent 不应该默认拥有完整 shell。
至少要区分：
✓ 只读命令
✓ 本地构建命令
✓ 网络请求
✓ 文件删除
✓ Git 写操作
✓ 云 API 操作
✓ 凭证读取
把这些全塞进一个 terminal.run，就是懒。
懒到最后就是事故。
OpenClaw 这类框架为什么值得盯
这也是为什么我一直关注 OpenClaw 这类框架。
不是因为它一定比 Cursor 更好用。
也不是因为开源天然更安全。
而是它把一个重要问题摆到了台面上：
Agent 不是 IDE 功能，Agent 是运行时。
一旦你把 Agent 当运行时，就会自然开始考虑：
✓ profile
✓ approval hooks
✓ tool allowlist
✓ workspace isolation
✓ memory boundary
✓ MCP server trust
✓ plugin install scanner
✓ session transcript
✓ gateway policy
✓ channel permissions
这些东西没有一个适合做酷炫宣传视频。
但它们才是真正决定 Agent 能不能长期跑的东西。
Cursor 这次 CVE 也好，PocketOS 删库也好，本质上都在提醒同一件事：
AI 编程工具不能只卷“写得快”。
接下来要卷“怎么不把宿主机和生产环境一起带走”。
我的判断
这两天最值得看的，不是又一个“AI 工具排行榜”。
那种文章没什么意思。
真正值得看的，是这些安全事故和 CVE 开始密集出现。
因为这说明 AI 编程工具正在进入第二阶段。
第一阶段，大家问：
> 它会不会写代码？
第二阶段，大家开始问：
> 它会不会替攻击者执行代码？
这两个问题，中间隔着一个时代。
以前开发者打开陌生仓库，风险主要来自依赖安装和手动执行脚本。
现在开发者打开陌生仓库，风险还来自一个勤奋过头的 AI Agent。
它会帮你探索。
也会帮攻击者完成攻击链。
这就是 Agent 时代最讽刺的地方：
效率工具越自动，攻击路径越短。
所以别再把 AI 编程安全当成“Prompt 注入小技巧”了。
这已经是供应链安全、开发环境安全、权限模型、运行时隔离混在一起的新战场。
我的建议很简单：
如果你是个人开发者，不要让 Agent 直接在主力环境里跑陌生 repo。
如果你是团队负责人，不要把 Agent 当普通 IDE 插件审批。
如果你是安全团队，从今天开始，把 Cursor Rules、Claude instructions、OpenClaw skills、MCP 配置都纳入安全审查范围。
下一波真正的大事故，很可能不是“AI 写错了代码”。
而是：
AI 很认真地帮攻击者把 exploit 跑完了。
'''
