Plugin4Shell: When Your AI Coding Agent Auto-Updates Straight Into RCE

Plugin4Shell：当你的 AI 编程助手自动更新导致远程代码执行（RCE）

Zero-click RCE. Four major AI coding agents. No user interaction required. Let’s talk about Plugin4Shell. 零点击远程代码执行（RCE）。四大主流 AI 编程助手。无需任何用户交互。让我们来聊聊 Plugin4Shell。

The Incident

事件背景

In September 2026, researchers disclosed a vulnerability class dubbed “Plugin4Shell” affecting Claude Code, Codex, Gemini CLI, and Copilot. The flaw lives in how these agents verify SHA-pinned plugin commits pulled from marketplaces. Here’s the setup: you install a plugin, the agent pins it to a specific commit SHA, and in theory that SHA is your guarantee that the code you approved is the code that runs, forever. That’s the entire point of pinning. You audit once, trust persists. 2026 年 9 月，研究人员披露了一类被称为“Plugin4Shell”的漏洞，影响了 Claude Code、Codex、Gemini CLI 和 Copilot。该缺陷存在于这些助手验证从市场下载的、通过 SHA 锁定的插件提交的方式中。其机制如下：当你安装一个插件时，助手会将其锁定在特定的提交 SHA 上；理论上，该 SHA 是你所批准的代码能够永久运行的保证。这正是“锁定（pinning）”的全部意义所在：审计一次，信任持久。

Except the verification was broken. Attackers could swap a benign plugin for malicious code after the initial approval, or hijack the underlying repo the plugin points to. Because these agents auto-update plugins by default, the swap happens silently. No click, no prompt, no “are you sure.” One day your agent’s plugin is doing what it always did. The next, it’s running attacker-supplied code with full access to whatever the agent can reach — your filesystem, your credentials, your CI pipeline, your cloud accounts. That’s the “keys to the kingdom” framing in the original report, and it’s not hyperbole. Agentic coding tools are increasingly given broad local and network permissions specifically because that’s what makes them useful. Plugin4Shell turns that usefulness into blast radius. 但验证机制失效了。攻击者可以在你最初批准后，将良性插件替换为恶意代码，或者劫持插件所指向的底层仓库。由于这些助手默认会自动更新插件，这种替换会在静默中发生。没有点击，没有提示，也没有“你确定吗”的确认。前一天你的插件还在正常工作，后一天它就在运行攻击者提供的代码，并拥有对助手所能触及的一切——你的文件系统、凭据、CI 流水线、云账户——的完全访问权限。这就是原始报告中提到的“通往王国的钥匙”，这并非夸大其词。智能编程工具之所以被赋予广泛的本地和网络权限，正是为了提升其实用性。而 Plugin4Shell 将这种实用性转化为了攻击的破坏半径。

How This Actually Works (Mechanically)

技术原理

The core failure is a trust-verification gap, not a novel exploitation technique. SHA-pinning is supposed to be immutable: you pin to a commit hash, that hash’s content doesn’t change, full stop. If your agent’s checkout process doesn’t strictly enforce that the fetched content actually matches the pinned hash, or if it silently falls back to fetching “latest” under some auto-update condition, you’ve got a supply-chain hole disguised as a security feature. 核心故障在于信任验证的缺失，而非某种新颖的利用技术。SHA 锁定本应是不可变的：你锁定到一个提交哈希，该哈希的内容就不应改变，仅此而已。如果助手的检出（checkout）过程没有严格强制要求获取的内容与锁定的哈希完全匹配，或者在某些自动更新条件下静默回退到获取“最新版本”，那么你就拥有了一个伪装成安全功能的供应链漏洞。

The attacker doesn’t need to compromise your machine directly. They need to compromise or spoof the plugin source once, and then wait. Auto-update does the rest. This is the same category of problem as npm/PyPI supply-chain attacks, except the payload isn’t traditional malware sitting in a require() statement, it’s arbitrary code with agent-level tool execution privileges. Worse blast radius, same root cause: implicit trust in a dependency source that isn’t being re-verified on every fetch. 攻击者不需要直接入侵你的机器。他们只需要入侵或伪造一次插件源，然后等待即可。自动更新会完成剩下的工作。这与 npm/PyPI 供应链攻击属于同一类问题，区别在于其载荷不是位于 require() 语句中的传统恶意软件，而是拥有助手级工具执行权限的任意代码。破坏半径更大，但根本原因相同：对未在每次获取时进行重新验证的依赖源存在隐性信任。

What Existing Defenses Missed

现有防御措施的盲点

SHA-pinning is a good control. It’s also a control that everyone assumes “just works” once it’s in place, which is exactly the assumption Plugin4Shell exploited. Nobody’s watching the checkout step for anomalies because the checkout step is supposed to be a solved problem. Traditional endpoint security doesn’t help much here either. From the OS’s perspective, this is your legitimate, already-authorized AI coding agent making legitimate, already-authorized file and network operations. There’s no malware signature to catch. There’s no unusual process spawning something it shouldn’t. The agent is doing exactly what it’s designed to do: execute plugin code with the permissions you already granted it. SHA 锁定是一种很好的控制手段。但这也是一种人们默认其一旦部署就“万无一失”的控制，而这正是 Plugin4Shell 所利用的假设。没有人会去监控检出步骤中的异常，因为检出步骤本应是一个已解决的问题。传统的端点安全在这里也无济于事。从操作系统的角度来看，这是你合法的、已授权的 AI 编程助手在进行合法的、已授权的文件和网络操作。没有恶意软件签名可供捕获，也没有异常进程在生成不该生成的东西。助手正在执行其设计之初的任务：以你授予的权限执行插件代码。

The actual anomaly isn’t in the payload, it’s in the behavior around the fetch: a plugin checkout that doesn’t match its pinned commit, or a plugin that suddenly starts issuing tool calls it never issued before (reading credential files, hitting new network endpoints, writing to paths outside its normal scope). That’s a tool-abuse signal, not a malware signature. 真正的异常不在于载荷，而在于获取过程中的行为：插件检出与锁定的提交不匹配，或者插件突然开始发出以前从未发出的工具调用（读取凭据文件、访问新的网络端点、写入其正常范围之外的路径）。这是一种工具滥用信号，而非恶意软件签名。

Where Sentinel Fits: agentic_tool_abuse

Sentinel 的作用：智能体工具滥用防护

Sentinel doesn’t verify git commit hashes, and it’s not a replacement for fixing SHA-pinning verification upstream (that’s a real fix the agent vendors need to ship). What Sentinel does is sit on the agentic proxy path and watch what the plugin’s tool calls actually do once they start running, regardless of whether the underlying code was swapped legitimately or maliciously. Sentinel 不验证 Git 提交哈希，也不能替代上游对 SHA 锁定验证的修复（那是助手厂商需要提供的真正修复方案）。Sentinel 的作用是位于智能体代理路径上，监控插件工具调用在运行时的实际行为，无论底层代码是被合法还是恶意替换的。

This matters because Plugin4Shell’s actual damage isn’t the commit swap itself, it’s what the newly-malicious plugin does next with agent-level access: reading .env files, hitting exfiltration endpoints, writing to paths it has no business touching. That’s tool-result and tool-call traffic flowing through the agentic proxy (/v1/messages, /v1/grok, /v1/openai, /v1/gemini), and Sentinel scans it on the way through. 这一点至关重要，因为 Plugin4Shell 的实际危害不在于提交替换本身，而在于恶意插件随后利用助手级访问权限所做的事情：读取 .env 文件、访问数据外泄端点、写入其本不该触及的路径。这些工具结果和工具调用流量会流经智能体代理（/v1/messages, /v1/grok, /v1/openai, /v1/gemini），而 Sentinel 会在流量经过时对其进行扫描。

Two mechanisms from the reference architecture apply directly: 参考架构中的两种机制可以直接应用：

Secret & credential detection (Layer 5). If a hijacked plugin’s first move is to read local credential files, API keys, or tokens, and hand that content back through a tool result, Sentinel’s secret detector redacts known key formats (Anthropic, OpenAI, AWS, GitHub, Stripe, Slack tokens, Authorization: Bearer headers, and env-var assignments with sensitive names) before that content ever reaches the model. This runs independently of the threat-scoring pipeline. Even in a scenario where the malicious plugin’s exfiltration attempt doesn’t trip the fast-path or deep-path scorer at all, a leaked ANTHROPIC_API_KEY or AKIA… string gets caught and replaced with a placeholder before it reaches the agent’s context.
密钥与凭据检测（第 5 层）。 如果被劫持插件的第一步动作是读取本地凭据文件、API 密钥或令牌，并通过工具结果返回这些内容，Sentinel 的密钥检测器会在内容到达模型之前，屏蔽已知的密钥格式（如 Anthropic、OpenAI、AWS、GitHub、Stripe、Slack 令牌、Authorization: Bearer 请求头以及带有敏感名称的环境变量赋值）。这独立于威胁评分流水线运行。即使在恶意插件的外泄尝试未触发快速或深度路径评分的情况下，泄露的 ANTHROPIC_API_KEY 或 AKIA… 字符串也会在到达助手上下文之前被捕获并替换为占位符。
Source-risk trust scoring on tool results. The agentic proxy applies a provenance-aware trust multiplier to Read/Grep/Glob/Bash tool results. Critically, paths under known package-manager or plugin-install directories (node_modules, site-packages, vendor, .venv, and similar) never get the trust discount, even when nested under an otherwise-trusted developer directory. A compromised plugin living in a plugin-install path gets scanned at full sensitivity, not treated as trusted just because it sits inside your project tree. This closes exactly the gap Plugin4Shell relies on: an attacker banking on the fact that “installed and previously-approved” gets treated as “trusted forever.”
工具结果的源风险信任评分。 智能体代理会对 Read/Grep/Glob/Bash 工具结果应用基于来源的信任乘数。关键在于，已知包管理器或插件安装目录（如 node_modules、site-packages、vendor、.venv 等）下的路径永远不会获得信任折扣，即使它们嵌套在其他受信任的开发者目录下也是如此。位于插件安装路径中的受损插件会以最高灵敏度进行扫描，而不会仅仅因为它位于你的项目树中就被视为可信。这恰好填补了 Plugin4Shell 所依赖的漏洞：攻击者赌的就是“已安装且先前已批准”会被视为“永久可信”。

Neither of these requires knowing about Plugin4Shell specifically. They’re generic controls on tool-call behavior and tool-result content, which is why they catch this class of attack even though they were designed. 这两项机制都不需要专门针对 Plugin4Shell。它们是对工具调用行为和工具结果内容的通用控制，这也是为什么它们能够捕获此类攻击的原因。