你跑着 Claude Code，每天处理上百个 PR。它装了 3 个社区插件：一个自动生成测试用例，一个查 Jira 工单，一个监控 CI 状态。这些插件来自你信任的官方市场，每个都经过了代码审查，SHA 锁定到特定版本——安全团队签了字，合规过了关，一切看起来无懈可击。
但 SHA 锁定本身是假的呢？
2026 年 9 月 17 日，AIR Security 公开了一个命名为 Plugin4Shell 的零点击远程代码执行漏洞（CVE 待分配）。这不是一个常规的软件漏洞——它击穿了所有 AI 编码 Agent 共享的插件安全模型。Claude Code、OpenAI Codex、GitHub Copilot、Google Gemini CLI——四大主流 AI 编码 Agent 无一幸免。 截至目前，Anthropic 和 OpenAI 已发布补丁，Google 选择弃疗，而 GitHub 仍未修复。
Plugin4Shell：第一个 AI Agent 供应链漏洞
“这是 AI Agent 生态系统的第一个供应链漏洞，” AIR 的研究员 Or Nevo、Dor Granat 和 Niv Hoffman 在报告中写道。
⚠️ 关键数据一览：
| 维度 | 详情 |
|---|---|
| 漏洞名称 | Plugin4Shell |
| 发现者 | AIR Security（Or Nevo / Dor Granat / Niv Hoffman） |
| 发现时间 | 2026 年 5 月 |
| 披露时间 | 2026 年 6 月（厂商）；2026 年 9 月 17 日（公开） |
| 影响范围 | Claude Code / Codex / Copilot / Gemini CLI |
| 攻击类型 | 零点击远程代码执行 (Zero-Click RCE) |
| 漏洞根因 | Git SHA-pinning 后的 checkout 结果未验证 |
| CVSS 评级 | 高严重性（待官方分配） |
这是 AIR Security 第三次敲响 AI Agent 供应链安全的警钟。此前他们展示了 The Story of Skills（一篇恶意 skill 感染 26,000+ Agent）和 SkillJacking（925 个已上架 skill 被劫持，影响 134,000 Agent）。Plugin4Shell 是第三幕——这次，问题出在安全机制本身。
攻击链拆解：一个缺失的「git status」
第一层：SHA 锁定的信任假设
AI 编码 Agent 的插件系统依赖一个简单的安全模型：
- 市场（marketplace）对插件代码做代码审查
- 审查通过后，将插件「锁定」（pin）到一个特定 Git commit 的 SHA 值
- Agent 安装时，根据这个 SHA 去 checkout 指定版本的代码
这个模型假设：给出 SHA → Git checkout 该 SHA → 得到的代码就是被审查过的代码。
但 Agent 只做了前半段——把 SHA 传给 Git——却从未验证 Git 实际 checkout 的代码是否匹配这个 SHA。
第二层：分支名冒充 SHA
攻击者控制了一个插件仓库（通过上架良性插件后作恶，或直接攻破已有插件的仓库），然后创建一个新的分支，把分支名设为被锁定 commit 的 40 字符 SHA 值。
当 Agent 执行 git checkout <SHA> 时，Git 的引用解析逻辑会优先匹配分支名而非 commit 对象。结果：Agent 以为自己 checkout 了被审查的 commit，实际运行的却是恶意分支上的代码。
Claude Code、Codex、GitHub Copilot 三者的攻击路径完全相同。Gemini CLI 有独立的变体——它使用 FETCH_HEAD 作为 checkout 目标，攻击者只需创建一个同名分支即可重定向。
第三层：自动更新让攻击零点击
这不是一个需要你「安装恶意插件」的漏洞。你只需要正常安装过一个插件。
Claude Code 和 Codex 默认在后台自动更新插件。当攻击者在市场上更新了插件的 pinned SHA（比如通过一个看似无害的 PR 获得批准），然后执行 rug-pull——将新版本替换为恶意代码——Agent 的自动更新机制会在后台静默执行恶意 checkout，不需要用户任何点击或确认。
第四层：跨市场覆盖
GitHub 声称其在 GitHub.com 上禁止创建与 SHA 同名的分支或标签，但这不足以防御 Plugin4Shell。插件市场同样可以托管在 Bitbucket、GitLab 等平台上——而 Claude Code、Codex、Copilot 都官方支持这些平台。GitHub 的防护只覆盖了 GitHub 生态内的一小部分。
补丁状态：两家已修，两家仍未
| 厂商 | 产品 | 状态 | 说明 |
|---|---|---|---|
| Anthropic | Claude Code | ✅ 已修复 | 版本 2.1.179 |
| OpenAI | Codex | ✅ 已修复 | 版本 0.146.0 |
| Gemini CLI | ❌ 不修复 | 已弃用，建议迁移到 Antigravity | |
| Microsoft / GitHub | Copilot | ❌ 未修复 | 声称 GitHub 的命名限制足够，AIR 反驳称跨平台市场不受此限制 |
最令人担忧的是 GitHub Copilot。近 90% 的 Fortune 500 企业使用 Copilot，覆盖面极广。AIR 团队自 6 月起就向微软报告了此漏洞，但「由于他们当前收到的披露量太大，我们没有得到回应」。
不止于孤立漏洞：设计范式的系统失效
Plugin4Shell 最值得警惕的不是它的攻击技巧，而是同样的设计错误重复出现在所有主流 Agent 中。
这不是某个厂商产品中的一个实现偏差——它是整个行业对「安全锁定」这一概念的共同误解。Agent 开发者们认为「给了 SHA 就是安全的」，却忽略了关键的验证步骤。四种不同实现、四个不同厂商、相同的缺失。
这与此前我在 《Agentjacking 横空出世！一个假 Sentry 错误报告就能劫持你的 AI 编码 Agent》 中分析的攻击模式如出一辙：安全层的弱点不在「入口」，而在「验证」。
防御方案：分层应对
面对 Plugin4Shell 这类供应链攻击，企业可以从四个层面构建防御：
架构隔离：AI 编码 Agent 不应直接运行在与生产环境同权限的网络中。Agent 工作站应当视为高敏感端点，与开发/CI/CD 环境做网络微隔离。
输出净化：Agent 安装插件时的 Git checkout 操作应增加额外的完整性验证。不仅仅是信任 Git 的返回值，而是手动比较 checkout 结果的 HEAD commit 是否与预期的 SHA 一致。
沙箱强化：即使插件被攻破，Agent 的运行时权限也应以最小权限原则执行。容器化运行 Agent，限制文件系统访问和网络出口——这和 《Agent Supply Chain Attack：从 MCP 配置投毒到供应链污染》 中提出的防御建议一致。
供应链治理：企业应建立内部插件白名单，禁止直接使用公共市场未审查的插件。所有插件需经过内部安全团队的二次审查和签名验证。
写在最后
Plugin4Shell 的杀伤力不只在于它的技术细节，而在于它暴露了一个更深层的事实：AI Agent 生态的安全假设还停留在上个时代。 我们给了 Agent 最高权限——访问源代码、云凭据、CI/CD 管道——却在插件分发层用了一句未经验证的 git checkout 来保证安全。
AIR 团队在披露中说得最直白的一句话我反复读了几遍，它应该被每个使用 AI 编码 Agent 的团队记住：
“这是一个市场无法修复的漏洞，用户必须更新自己的 Agent。”
安全不是买来的功能，而是每一个 git checkout 之后多问一句：你确定你拿到了你想要的代码？
📌 延伸阅读：
- 《Agentjacking 横空出世！一个假 Sentry 错误报告就能劫持你的 AI 编码 Agent》 — 同一研究方向：利用 MCP 集成的另一端漏洞攻陷编码 Agent
- 《Agent Supply Chain Attack：从 MCP 配置投毒到供应链污染》 — Agent 生态供应链安全的系统性风险
- AIR Security 完整报告：https://www.air.security/blog-posts/plugin4shell