跳到正文
原文
Permission Protocol · AI Agent Incident Tracker·· 2026/04/15精选AI 评分87

约翰霍普金斯研究者通过 PR 标题注入从 Claude Code、Gemini CLI 和 GitHub Copilot 窃取 API 密钥

原文标题：Johns Hopkins researchers steal API keys from Claude Code, Gemini CLI, and GitHub Copilot via PR title prompt injection, all three vendors paid bug bounties quietly

AI 导读

约翰霍普金斯研究者 Aonan Guan 利用 PR 标题提示词注入，从 Claude Code Security Review、Gemini CLI Action 和 GitHub Copilot 中窃取 API 密钥与 GitHub token。

推荐理由

约翰霍普金斯研究者用 PR 标题注入从三个 AI 编程智能体中窃取凭据，三家厂商均静默修复并支付漏洞赏金。

正文 · AI 翻译

译文尚不完整，完整内容请切换到原文。

返回事件跟踪器

2026-04-15

高主要

约翰斯·霍普金斯大学的研究人员通过 PR 标题提示注入，从 Claude Code、Gemini CLI 和 GitHub Copilot 中窃取了 API 密钥，三家厂商都悄悄支付了漏洞赏金

约翰斯·霍普金斯大学的研究人员利用 PR 标题提示注入，从 Claude Code、Gemini CLI 和 GitHub Copilot 中窃取 API 密钥和 GitHub 令牌。三家厂商都支付了漏洞赏金，却没有发布 CVE 或安全公告。

Claude Code 安全审查 / Gemini CLI Action / GitHub Copilot凭据泄露通过 GitHub Actions 实施的提示注入凭据窃取GitHub Actions CI/CD 流水线 / 仓库密钥

发生了什么

恶意的 PR 标题载荷劫持了 Claude Code 安全审查，让它执行 bash 命令，窃取环境变量和 API 密钥，再以 PR 审查评论的形式发出来

为什么重要

ANTHROPIC_API_KEY、GITHUB_TOKEN、云服务商凭据，以及 Actions 运行器能访问到的其他仓库密钥全部暴露。厂商悄悄修复，导致数量不明的仓库仍停留在有漏洞的版本上，却收不到任何通知。

缺少授权检查

运行时门禁：AI 智能体执行工具调用（bash、读取环境变量、访问密钥）之前，必须先获得人工明确批准，而这些调用由不可信的 PR 作者输入触发

PP 能拦住吗？

在 PP 管控的部署里，智能体的工具调用（执行 bash、读取环境变量）都需要签名回执。回执请求会推到人工操作员面前：“Claude Code 安全审查正在请求执行 bash，由 PR #68 触发——批准吗？”恶意的 PR 标题生成不了有效回执——只有带凭据、通过 MFA 的签名者才能生成。这是典型的混淆代理人攻击：智能体继承了它根本不需要的凭据，又分不清哪些是可信操作员的指令、哪些是攻击者注入的载荷。PP 在工具调用边界就把攻击拦下，任何凭据都还没被碰到。

事件分析

Timeline and technical read

Timeline

  1. 2025-10

    Aonan Guan (Johns Hopkins) submits initial prompt injection finding against Claude Code Security Review to Anthropic via HackerOne

  2. 2025-11

    Anthropic pays $100 bug bounty, upgrades severity from CVSS 9.3 to 9.4; updates documentation with security warning; no CVE assigned, no public advisory

  3. 2026-Q1

    Guan extends attack to Google Gemini CLI Action and Microsoft GitHub Copilot — both vulnerable, both pay bug bounties without advisories

  4. 2026-04-15

    The Register publishes exclusive interview with Guan; research published at oddguan.com

  5. 2026-04-16

    GBHackers 的二次报道和 Winbuzzer 都证实了这一点：固定版本的用户被静默打了补丁，但暴露风险依然存在

技术剖析

  • 攻击向量：PR 标题注入——三款受影响的 agent 都把 GitHub 数据（PR 标题、issue 正文、评论）当作可信的任务上下文来读，于是任何有仓库权限的 PR 作者都能借此劫持它们
  • 三款 agent 的脆弱数据流完全一样：读 GitHub 数据 → 当作任务上下文处理 → 用 Actions runner 的完整权限执行工具调用
  • 外泄后的清理：攻击者把 PR 标题改回无害文本（“fix typo”），关掉 PR，删掉机器人的审查评论——几乎不留取证痕迹
  • 泄露的凭据包括 GITHUB_TOKEN、ANTHROPIC_API_KEY，以及 Actions runner 环境能拿到的各种云厂商密钥
  • Guan 估计，这种模式适用于所有接入 GitHub Actions 的 agent——Slack 机器人、Jira agent、部署自动化工具——而不只是已确认受影响的三家厂商

授权边界

授权边界本该设在哪里

这次事件归类为凭据泄露，对应的 Permission Protocol 门禁是凭据门禁。这条读取规则是有条件的：只有当真正的操作边界经过门禁时，该限制才生效。

若在以下位置强制执行
AI 智能体工具调用边界（bash 执行、环境变量和密钥读取）
仍需处理
使用上游 GitHub Actions 且没有 PP 管控封装的仓库——这些 Actions 默认不受保护，即使锁定版本也依然存在风险
需要收据的场景
AI 智能体做 PR 审核期间触发的 bash 执行、环境变量读取，以及任何密钥访问

PP 在工具调用层强制执行——智能体执行 bash 命令或读取环境密钥之前，必须先拿到收据。攻击者注入的 PR 标题没法给自己签发收据，只有持有凭据的人工签署者才能签发。这正是 PP 要解决的“混淆代理人”问题。

从小处着手

把对应的门禁放在这个操作边界上。

这次事件对应凭据门禁。先从控制实际操作的边界入手，再要求执行前必须提交已签署的收据。

来源：Permission Protocol · AI Agent Incident Tracker · permissionprotocol.com

#安全/事故#Agent#GitHub#Anthropic#Google#OpenAI