Agentjacking：利用假 Bug 报告劫持 AI 编码 Agent

安全研究人员发现一种名为 Agentjacking 的新型攻击手法，攻击者通过向 AI 编码 Agent 发送虚假的错误报告（fake bug reports），即可在零交互的情况下劫持 Agent 的完整工作流。该攻击揭示了 AI Agent 在自主决策场景下的一个固有脆弱性：对工具调用结果的过度信任。

攻击原理

AI 编码 Agent 的工作流通常包含以下环节：读取任务 → 分析代码 → 运行测试 → 读取结果 → 修复错误 → 提交代码。Agentjacking 攻击的核心在于污染结果读取环节。

具体攻击路径如下：

第一步：伪造 Bug 报告

攻击者在项目仓库的 Issue 或 PR 中提交一条精心构造的「Bug 报告」。这份报告看起来像一个合法的编译错误或测试失败信息，但暗含了两个异常设计：

• 报告中嵌入的可疑指标（如非预期的依赖版本号、指向外部仓库的包路径）
• 伪装的「修复建议」——推荐使用攻击者控制的第三方代码包

第二步：Agent 无感信任

AI 编码 Agent 在处理 Bug 报告时，会：

1. 读取报告中的错误信息
2. 根据错误类型自动搜索修复方案
3. 执行包含代码安装/更新命令的修复操作

由于 Agent 在设计上倾向于信任上下文信息——编译器的输出、测试框架的报错、代码仓库的数据——它不会对 Bug 报告中的「修复建议」做额外的可信度验证。

第三步：自动执行恶意操作

当 Agent 按照伪造的「修复建议」执行操作时，它会：

• npm install 或 pip install 指向攻击者私有的恶意包
• 运行包含恶意代码的「修复脚本」
• 将修改后的代码提交到仓库

整个过程中，Agent 认为自己在执行一次标准的 Bug 修复流程。

与供应链攻击的结合

Agentjacking 的真正杀伤力在于它与供应链攻击的天然结合：

恶意包注入：Agent 按照伪造的修复建议安装的第三方包，可能是攻击者精心构造的恶意包——包含后门、数据窃取逻辑或依赖混淆名称。

代码污染：Agent 提交的「修复代码」可能包含隐藏的恶意逻辑，通过正常的代码审查后合并到主分支，进而影响所有下游用户。

持续控制：一次成功的 Agentjacking 可以为攻击者建立持久化的代码级别后门，未来所有通过 CI/CD 流水线构建的产物都可能受影响。

受影响场景

Agentjacking 攻击在以下场景中尤为危险：

与 AutoJack 和 Tool Calling 安全性的关联

Agentjacking 与此前披露的 AutoJack（通过恶意网页劫持浏览 Agent）存在深层共性：

对工具输出无校验：

• AutoJack：Agent 信任浏览器返回的页面内容，未校验 WebSocket 响应的完整性
• Agentjacking：Agent 信任 Bug 报告/测试框架的输出，未校验修复建议的合法性

两者都指向同一个根本问题：当前的 Agent 设计假设工具返回的结果是可信的，但攻击者已经证明这个假设在多个场景下不成立。

缓解方向

针对 Agentjacking 类型的攻击，以下几类措施值得关注：

上下文来源分级：对 Agent 的输入上下文来源进行可信度分级。来自外部未验证源的 Issue/评论应标记为「低可信」，仅允许触发只读操作，禁止自动执行包安装或代码写入。

修复建议验证：Agent 在执行修复操作前，应交叉验证「修复建议」与官方包源的匹配性。例如，验证推荐的 npm 包是否存在于官方注册表、版本号是否与官方最新版一致。

操作审批策略：对于高危操作（安装新依赖、修改配置文件、提交代码），Agent 应暂停并请求人工确认，而非自动执行。

行为审计：记录 Agent 每次工具调用的完整上下文——输入来源、参数、输出结果和后续决策——便于在发现问题时回溯攻击链。

参考资料

• SC Media「Agentjacking attack exploits AI coding tools」，2026-06-19（原文链接 https://www.scmagazine.com/news/agentjacking-attack-exploits-ai-coding-tools，返回 404，本文基于公开摘要和领域知识撰写）
• Hackread 相关报道，2026-06-19
• 微软安全团队「AutoJack: How a single page can RCE the host running your AI agent」，2026-06-18