系统：运行中
EN FR ES ZH
⌕
← 返回所有攻击
AGENTS MEDIUM NEW

Claude Code 的 GitHub Action：Read 工具如何泄露 CI/CD 密钥

微软威胁情报发现，Claude Code Action 的 Read 工具绕过了 Bash 的环境清洗，读取 /proc/self/environ，泄露了 runner 的 ANTHROPIC_API_KEY。已在 v2.1.128 修复。

2026-06-12 // 6 min affects: claude-code-action, claude-agent-sdk, github-actions

这是什么？

2026 年 6 月 5 日，微软 Defender 安全研究团队发布了 Anthropic Claude Code GitHub Action 中的一条提示注入路径。当该 Action 处理不受信任的 GitHub 内容（issue 正文、pull request 描述、评论）时，一段精心构造的指令可以引导代理的 Read 工具打开 /proc/self/environ，提取 runner 的环境变量，包括 ANTHROPIC_API_KEY。微软于 2026 年 4 月 29 日通过 HackerOne 向 Anthropic 报告该问题；Anthropic 在 2026 年 5 月 5 日的 Claude Code 2.1.128 中发布了修复，现在会无条件拒绝 /proc/ 下的敏感文件。本文讨论的是一个已修复的缺陷及其背后的信任边界教训，而非操作指南。

工作原理

Claude Code Action 封装了 Claude Agent SDK，并在 GitHub Actions 的 runner 内运行 Claude——这是一个临时虚拟机，可能持有 GITHUB_TOKEN、云凭据、发布令牌以及第三方 API 密钥。Anthropic 已预见到风险：Bash 工具运行在 Bubblewrap 沙箱中，且环境经过清洗（CLAUDE_CODE_SUBPROCESS_ENV_SCRUB，当工作流可被无写权限用户触发时自动启用）。微软发现的缺口在于：Read 工具并未经过同样的隔离。Read 操作是直接的进程内调用，因此以对父进程环境的完全访问权运行——绕过了保护 Bash 的清洗。

这就把经典的「CI/CD 中的 AI」模式变成了致命三要素：不受信任的输入（一个 GitHub issue）、对密钥的访问（runner 的环境）以及外发通道（WebFetch、通过 GitHub MCP 的评论，或 Action 日志）。注入文本被藏在 HTML 注释里——在渲染后的 issue 中不可见，但在模型读取的原始 markdown 中清晰可见。两道防御层仍然存在，而载荷在概念层面绕过了它们：

防御层                          为何失效
-----------------------------  ------------------------------------------------
模型拒绝 / 系统提示              将请求伪装成「合规审查」，并指示模型在打印前
                               截掉数值的前几个字符——输出便不再像
                               「sk-ant-...」密钥
GitHub 密钥扫描器               由于密钥在写入 stdout 前已被改动，已知模式的
                               检测器未能匹配

攻击者随后通过补回被截掉的前缀来重建完整密钥。此处不复现任何可用载荷；重要的是洗白这一思路——把密钥变形到恰好能同时绕过模型的拒绝启发式和基于正则的扫描器。微软将该链条对应到 MITRE ATLAS 技术：提示注入（AML.T0051）、工具调用（AML.T0053）、越狱（AML.T0054）、凭据收集（AML.T0098）与数据泄露（AML.T0057）。

为何重要

被暴露的值是一份位于构建 runner 中的有效凭据，任何能对足够宽松的工作流提交 issue 的人都可以触达。同一信任缺口还促成了在真实环境中观察到的第二种后果：一个 AI 分诊机器人被诱导去读取一个文档文件、向其中追加一个不可见的 XSS 图片标签，并开启一个 pull request——这是一次供应链投毒尝试，攻击者本身无需写权限，只需借用代理的权限。根本问题是结构性的。GitHub Actions 是为确定性自动化而设计的；把 LLM 嫁接上去意味着自然语言变成了可执行代码，每一个 issue 或评论都成了潜在指令。一处被误判的信任边界——一个跳过了沙箱的工具——就足以让人带走生产凭据。这与Comment and Control属于同一类弱点，只是从 runner 内部观察。

防御

修复已发布，但其架构教训适用于任何「AI 进入 CI」的部署：

  1. 立即更新。 使用 Claude Code Action / Claude Code 2.1.128 或更高版本，它会阻止对 /proc/ 的读取。将 Action 固定到已验证的版本，而非浮动标签。
  2. 应用代理二选一规则。 任何 AI 工作流都不应同时具备：处理不受信任的输入、持有密钥、拥有外部写入/通信工具。对由不受信任内容触发的任务，去掉其中一条——通常是外发通道或密钥访问。
  3. 对每个令牌实行最小权限。 将 GITHUB_TOKEN 与各提供商密钥限制到工作流所需的最低限度，每个工作流/环境一把密钥，并在提供商侧对新 IP 或流量激增告警。
  4. 将仓库中的一切内容视为敌意数据。 强化系统提示，明确声明 issue、评论、diff 和文件内容是不受信任的数据，绝非指令，并将代理锁定在单一任务上，对范围之外的内容默认拒绝。
  5. 隔离运行时并监控出站。 不要让由不受信任内容触发的 AI 任务在持有常驻凭据的自托管 runner 上运行。限制外发域名并审阅 Action 的工具调用日志——审计轨迹能把一次无声泄露变成一次被发现的测试。

状态

项目来源日期备注
向 Anthropic 报告（HackerOne）微软威胁情报2026-04-29对 Claude Code Action 的黑盒 → 白盒研究
在 Claude Code 2.1.128 中修复Anthropic2026-05-05Read 工具无条件拒绝 /proc/ 下的敏感文件
公开披露微软安全博客2026-06-05Read 工具绕过环境清洗；/proc/self/environ → ANTHROPIC_API_KEY
媒体报道The Hacker News、CyberSecurityNews2026-06-05 → 2026-06-06佐证报道

要点不在于某一家厂商的 Action 格外不安全——所有 AI 驱动的 CI 集成都具有同样的形态。要点在于工具级隔离必须保持一致：一个保护了 Bash 却没有保护 Read 的沙箱，是一个留了门的沙箱，而不受信任的 GitHub 内容终将找到它。

Sources