Manifold Security披露四大编码智能体共享漏洞：恶意git仓库可在Claude Code、Codex、Cursor与Grok上触发代码执行

9月2日消息，安全公司Manifold Security公开披露了一类影响整个编码智能体赛道的共享漏洞：一个不受信任的git仓库，能够跨Claude Code、OpenAI Codex、Cursor与xAI Grok四大主流编码智能体触发本地代码执行。研究人员用’同一类bug、四个智能体、一个下午全部中招’来形容这次发现的普遍性——攻击者只需诱导智能体克隆一个精心构造的恶意仓库，即可在开发者本机上执行任意命令。这一披露为高速普及的AI编码助手敲响了供应链安全警钟。

一、漏洞原理：恶意仓库如何劫持智能体

这类漏洞的根源，在于编码智能体的工作方式天然赋予了它过高的本地权限。当代编码智能体为了完成’读代码、改代码、跑测试、提交版本’等任务，普遍被授予本地shell访问权限，能够执行git clone、安装依赖、运行构建脚本等操作。当用户让智能体去分析或修复某个第三方仓库时，智能体会自动执行git clone将仓库拉取到本地，并可能进一步触发仓库内的各类自动化机制。

恶意仓库正是利用了这一信任链。git本身支持多种在克隆或操作时自动执行的机制，例如钩子（hooks）、子模块、配置项以及随仓库分发的安装脚本。攻击者在仓库中预置恶意的钩子文件或配置，当智能体克隆仓库并执行常规操作时，这些机制便会被触发，进而运行攻击者指定的命令。由于命令运行在智能体的权限上下文里，而智能体又拥有shell权限，恶意代码便获得了与智能体相当的本机执行能力——可以读取环境变量中的API密钥、访问SSH凭据、窃取源代码，甚至横向渗透到开发者所在的企业内网。

研究人员强调，这并非某一家厂商的孤立实现缺陷，而是整个agentic编码范式的系统性问题。四个智能体在一个下午内全部被同一种手法攻破，说明’克隆即执行’的攻击面在赛道中普遍存在，差异只在触发细节。智能体为了’好用’而被赋予的自动化权限，与安全所需的最小权限原则之间，存在深刻矛盾。

二、攻击面扩大：从依赖投毒到智能体供应链

此次披露揭示了AI编码助手带来的供应链攻击面正在显著扩大。传统软件供应链攻击主要针对依赖包投毒、CI/CD管道劫持等环节，开发者尚且有审核依赖、锁定版本等成熟防线。但编码智能体引入了一条全新的、自动化程度更高的信任路径：智能体会主动从远程拉取代码、自动安装依赖、自动运行脚本，而且这些动作往往在用户没有逐条审查的情况下由模型自主决定完成。

更危险的是智能体的’主动性’。与人类开发者不同，智能体在面对陌生仓库时会倾向于’先把环境跑起来’——它可能未经提示就执行npm install、pip install或仓库自带的初始化脚本，以期理解项目结构。这种为了完成任务而积极行动的特性，恰好与攻击者’诱导执行’的目标完美契合。攻击者甚至可以在仓库的README或代码注释中嵌入提示注入（prompt injection）内容，操纵智能体主动去执行某些’看起来合理’的命令，把社会工程学直接作用于模型而非人类。

由于编码智能体通常接入企业代码库、生产环境凭据与云平台令牌，一旦被劫持，其危害远超普通开发者终端失陷。一个被攻陷的智能体可能成为潜入企业研发体系的跳板，导致源代码泄露、构建产物被植入后门、乃至生产环境被入侵。随着企业大规模部署编码智能体，这条攻击路径的规模化风险不容忽视。

三、权限过大：智能体安全的核心症结

四大智能体集体中招，折射出当前AI编码工具在权限设计上的通病：默认过度授权。为了追求开箱即用的流畅体验，多数智能体在默认配置下拥有对工作目录乃至整个用户环境的读写与执行权限，缺乏细粒度的权限边界。智能体运行在与用户相同的权限上下文中，没有强制沙箱隔离，使得任何被诱导执行的命令都能直接触达用户的全部资源。

这与传统安全模型形成鲜明对比。在成熟的工程实践中，不可信代码应在隔离环境（容器、虚拟机、沙箱）中运行，并遵循最小权限原则。但编码智能体为了方便地读写项目、调用本地工具链，往往绕开了这些隔离措施，把’可信用户行为’与’不可信外部代码’混在同一执行环境里。当智能体克隆的仓库本质上是不可信输入时，这种混淆就埋下了致命隐患。

此外，权限问题还体现在凭据管理上。智能体能够读取环境变量、git凭据、云CLI配置等敏感信息，一旦执行环境被恶意代码控制，这些凭据会被立即收割。研究人员建议，智能体应在默认情况下以低权限、无持久凭据的模式运行，对高权限操作实行显式审批，并把’处理不可信仓库’与’访问敏感凭据’两类活动在进程与环境层面彻底隔离。

四、开发者防护建议

面对这一现实威胁，开发者与团队可以立即采取多层防护措施。首先是仓库来源验证：只让智能体处理来自可信来源、经过审查的仓库，对陌生或可疑仓库保持高度警惕，尤其要警惕那些通过Issue、社区链接、‘一键修复’诱饵诱导智能体克隆的外部仓库。企业应制定策略，明确智能体可访问的仓库白名单。

其次是沙箱执行。在条件允许的情况下，应让编码智能体在隔离环境中运行——例如使用容器、虚拟机或专门的沙箱工具，限制其对宿主机文件系统、网络与凭据的访问。将智能体的工作目录与存放密钥、生产配置的目录分离，避免智能体进程直接接触SSH密钥、云令牌等敏感资产。对于必须在本机运行的场景，也应使用低权限的专用账户，并关闭对敏感环境变量的访问。

第三是落实最小权限与审计。定期审查智能体可用的工具与命令，禁用不必要的自动执行行为；关闭或限制git钩子、自动安装依赖等高风险自动化环节；对智能体执行的命令保留完整日志，便于事后追溯。开发者还应养成习惯，在让智能体处理第三方代码前先人工检查仓库中的钩子目录、安装脚本与可疑配置文件，把’克隆即运行’改为’先审查再运行’。

五、厂商响应与修复进展

Manifold Security在公开披露前遵循了负责任披露流程，将漏洞细节同步给了四家厂商。各方响应速度与修复方案存在差异，但普遍承认了问题的严重性。Anthropic、OpenAI等厂商被指在智能体的默认权限模型与仓库处理流程上进行了收紧，包括对克隆仓库的自动执行行为增加确认环节、限制钩子等自动机制的触发、以及改进沙箱隔离。部分厂商还加强了对提示注入的检测，防止仓库内文本操纵智能体行为。

研究人员指出，单点修复虽能缓解当前利用手法，但无法根除’智能体拥有过度权限’这一根本问题。真正的解决需要赛道层面的架构升级：默认沙箱化、最小权限、对不可信内容的强制隔离，以及把’执行外部代码’从默认允许改为默认拒绝、显式授权。这要求厂商在’易用性’与’安全性’之间重新取舍，不能再为追求流畅体验而让安全成为可选项。

此次披露也可能推动行业标准的形成。安全社区已开始呼吁建立编码智能体的安全基线，明确智能体在处理不可信代码时应具备的隔离、审批与审计能力。随着监管机构对AI工具安全关注度的提升，这类共享漏洞有望成为推动agentic安全工程标准化的催化剂。

市场反应与行业影响

漏洞披露后，开发者社区与企业安全团队反应强烈。技术社交平台上，大量工程师分享了自查智能体权限、清理环境凭据、迁移到沙箱环境的经验，‘你的AI编码助手可能正以你的全部权限运行不可信代码’成为广泛传播的警示。安全分析机构普遍认为，这是2026年AI供应链安全领域最具代表性的事件之一，它第一次以如此直观的方式证明：编码智能体的安全风险不是理论假设，而是当下即可被利用的现实威胁。

对厂商而言，短期的修复与公告固然必要，但更深层的影响在于竞争逻辑的微妙变化。随着企业客户把安全纳入采购决策，‘默认是否沙箱化’‘权限是否最小化’‘是否通过独立安全评估’可能成为编码智能体新的竞争维度。在能力趋同的背景下，安全架构更稳健的产品有望赢得受监管行业与大型企业的青睐。

从行业影响看，这一事件与同期AI智能体安全赛道的融资热潮相互印证——当智能体大规模进入开发、运维与业务核心流程，保护智能体行为本身正在成为一个独立且紧迫的安全品类。对整个agentic生态而言，四大智能体’一个下午全部中招’是一记清醒的警钟：在赋予AI越来越强行动能力的同时，行业必须同步建设与之匹配的权限隔离、供应链审查与运行时防护体系，否则越强大的智能体，越可能成为被攻击者利用的强大武器。