老把戏,新靶心:Bash 正威胁 AI 编程代理供应链安全

研究人员测试了 11 个流行的开源代理（包括 Hermes、OpenCode、Roo-code 等）。实验结果表明，其中 10 个至少存在一类可被利用的防护绕过路径，仅 1 个代理（Continue）在全部测试类别中未发现绕过情况。研究将所用绕过手法分为五类（A 至 E），包括引号移除、$IFS、命令替换、base64 转 shell、破坏性 argv 标志等——这些均是有数十年历史的 shell 技巧，能够系统地击溃当今最流行开源 AI 代理的防护机制。其中 E 类成功率最高，它能绕过最多的防护，包括基于标记化的最强防护。

为什么会发生？

根本原因在于防护机制与 Bash 实际执行之间的不匹配。代理通常使用基于模式匹配的 shell 防护，检查原始文本，但系统 shell（Bash）在执行命令前会对文本进行展开、移除引号和重写。因此，代理认为自己在运行的命令与 Bash 实际运行的命令存在差异，这一结构性缺口正是 GuardFall 得以成立的基础。

研究人员归纳出四种架构性失效模式：在所调查的代理中，有三个（Hermes、opencode、Goose）虽然内置了防护但均被绕过；其余代理的失效形式各不相同——有的采用基于标记化的防护，但在带引号替换和破坏性标志处存在泄漏；有的完全没有静态防护；有的依赖沙盒，但一旦切换至文档中允许的本地/自动模式便会失效。单纯“增加更多拒绝列表模式”无法解决其中任何一个问题。

此外，此类利用还依赖前置条件：虽然直接的恶意提示词往往会被模型拒绝，但代理在摄入操作上下文（如被投毒的 README 或 Makefile）时，很容易诱使前沿模型将注入的命令作为常规任务发出。这一攻击链依赖于模型和上下文框架——研究实际测试使用的是 Claude Sonnet 4.6。

造成的影响

由于这些代理以开发者的完整账户权限运行，攻击者可利用 GuardFall 悄无声息地执行命令，例如窃取 AWS 凭证或清空整个开发环境，尤其在 CI 流水线中（“自动确认”模式常为默认），风险会放大，进而演变为重大的供应链风险。

在测试的 11 个代理中，仅有 1 个（Continue）未出现可被利用的绕过路径；其余代理均在不同类别上存在缺陷。研究人员将 Continue 视为在其默认 IDE 模式下能够在结构上封闭大部分绕过路径的参考设计，它是针对大多数开发者实际运行配置（代理在宿主机上运行、真实 $HOME、非一次性工作空间）的有效防御方案。另一种常见方案沙盒，仅在可以丢弃工作空间的配置下才有效。

应对措施

针对该问题，研究人员提出了临时缓解措施（如限定 shell 作用域、重定向 $HOME、禁用自动确认等），但强调这些仅为权宜之计。长期解决方案需由代理维护者在其内部实现更严格的命令评估机制，以弥合模式匹配防护与 Bash 实际执行之间的结构性差距。