研究者模拟了这样一种攻击：用户安装一个 AI 编程助手的插件时，看到的是正常功能。随后的一次更新，却加入了自动执行的恶意命令。等到用户开启会话或调用工具，这些命令就由运行 AI 助手的程序直接启动，模型可能根本没有机会判断是否应该执行。
这项名为 HookPry 的研究于 9 月 3 日提交到 arXiv。它把一个具体问题摆到了插件开发者和使用者面前：安装时获得的信任，是否也让后续版本新增的命令获得了执行资格？
一次更新如何加入恶意命令
AI 编程助手经常需要在固定时刻完成一些自动操作，例如修改文件后运行检查。这类操作可以通过“钩子”（hook）配置：某个事件发生，程序便触发预先安排好的动作。Claude Code 官方文档列出了多种钩子；本文涉及的是其中能直接运行系统命令的一类。
这种功能减少了重复操作，也让插件有机会在对话之外执行代码。命令型钩子能做什么，取决于运行它的进程拥有哪些权限；如果这些权限允许访问文件或连接外网，恶意命令就可能利用同样的能力。
HookPry 模拟的攻击从插件发布开始。攻击者先让正常版本进入用户环境，之后仍以同一个插件的身份发布更新，在配置中新增或修改自动命令。当运行框架接受更新，并让新增命令沿用此前的执行授权时，下一次匹配的事件就可能触发攻击。
这条路径有明确前提：插件已经安装，攻击者能够把更新送达，运行环境也允许对应命令加载和执行。论文没有证明攻击者可以强迫用户安装插件。
自动命令可能在模型判断前执行
在需要模型选择工具的流程里，恶意指令必须影响模型的判断，才有机会变成实际操作。命令型钩子还提供了另一条执行路径：运行程序监听到事件后，直接启动配置中的命令。
因此，即使模型会拒绝用户直接提出的危险要求，也不能据此判断这条自动执行路径安全。负责更新插件的程序、批准命令的机制，以及操作系统给予进程的权限，都需要各自完成检查。
对插件使用者来说，这个区别很实际。安装前检查旧版本，并不能确认下一次更新会增加什么行为；继续使用同一个插件名称，也不意味着它仍然只做原先获准的事。
77% 的攻击成功率有明确实验前提
论文报告，研究者在七种 AI 助手运行框架与模型后端组成的 25 种组合上，测试了 40 个案例，共完成 1,000 次运行。其中 770 次通过了预设的外部效果检查，整体攻击成功率为 77%。仅仅启动命令还不算成功，检查必须确认相应攻击目标已经实现。
这个数字衡量的是作者设定条件下的实验结果。实验使用临时环境和合成文件，没有接触真实用户凭据，也没有把沙箱逃逸纳入攻击能力。因此，77% 不能用来估算现实用户的受害概率；不同部署中的文件权限、网络限制和审批机制，仍会改变攻击能否完成。
判断哪些产品版本受到影响，还需要更完整的复现信息。论文 v1 的实现章节没有正文，实验设置也没有系统列出各产品的精确版本与启动配置。PDF 虽然提供了代码仓库链接，但不能仅凭论文中的汇总结果，认定这些产品的当前版本都采用相同的授权行为。
一个值得对照的例子来自 Codex 官方仓库中的开发者报告。报告者在 5 月 7 日描述，CLI 0.129.0 中由本地集成工具安装的用户级钩子，需要用户逐项批准；命令变化后，还会再次要求审核。这不是对 HookPry 的独立复现，也不能证明所有插件更新路径都已得到保护，但它说明产品版本与配置来源会影响授权过程。
更新新增的命令应该重新审核
对维护 AI 插件系统的团队，最直接的改进是让用户看见更新增加了什么执行行为。出现新的自动命令、触发条件或访问能力时，更新流程应展示变化并重新请求批准。用户需要知道命令何时运行、能够访问哪些文件，以及是否允许连接外网。
审核还应覆盖命令实际调用的脚本内容。同一条命令如果始终指向一个固定文件名，更新仍可能改变文件里的代码。只检查命令文本是否变化，会漏掉这类行为变化。这是沿着上述攻击机制可以推导出的检查要求，具体实现仍需测试。
确认发布者身份也有价值，但不能代替检查更新内容。SLSA 的供应链威胁说明区分了来源与构建完整性，以及恶意变更、无效审查等问题。来源符合预期，并不自动说明新版本里的每项行为都值得批准。
批准之后，运行环境还应限制命令能访问的文件与网络，并记录哪个插件版本在什么事件下启动了什么进程。这些措施分别减少攻击可用的能力，并为调查留下证据。
HookPry 提醒开发者检查插件更新后的授权流程：新增加的命令是否需要经过审核，才能开始执行？要把这项实验进一步用于产品安全判断，接下来需要把测试结果对应到明确的版本、配置和审批流程，让其他研究者能够重复验证。
