hackerbot-claw 攻击事件深度解析：AI Agent 时代的安全警钟

hackerbot-claw 攻击事件深度解析：AI Agent 时代的安全警钟

当攻击者也开始用 AI Agent 自动化攻击，你的 GitHub Actions 还安全吗？

一、事件概述：hackerbot-claw 是谁？

hackerbot-claw 是 2026 年 2 月底出现的一个自动化攻击者，专门针对 GitHub Actions 和 LLM workflow 发起系统性攻击。

攻击时间线

时间	事件
2026-02-21 ~ 02-28	持续 7 天的自动化攻击
2026-02-27 ~ 03-02	Datadog 观测到跨 9 个仓库 / 6 个组织的多轮尝试
2026-03-01	StepSecurity 公开披露攻击详情

攻击数据（触目惊心）

• 12+ 个 PR / workflow 被触发
• 7 个目标中 4 个实现远程代码执行（RCE）
• 至少 1 次 成功外传带写权限的 GITHUB_TOKEN
• 16 个 PR、2 个 issue、8 条评论

这不是"理论上可能"，而是真实仓库、真实 workflow、真实 token 风险。

---

二、5 种攻击方式全解析

hackerbot-claw 的攻击不是碰运气，而是针对 GitHub Actions 常见脆弱模式的自动化回放。

1. pull_request_target + 不可信代码检出

典型案例： avelino/awesome-go

危险模式：

on:
  pull_request_target:

jobs:
  pr-quality:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: go run ./.github/scripts/check-quality/

为什么危险？

• pull_request_target 在 base repo 上下文 跑，有高权限
• 但检出了 攻击者 fork 的代码
• 然后执行了那份不可信代码

结果： 把 target repo 的 token/secrets 暴露给攻击者。

2. 直接脚本注入

典型案例： project-akri/akri

手法： PR 里修改脚本文件，再用 comment trigger 触发执行。

特点： 进入门槛低，很多维护脚本都可能中招。

3. 分支名注入

典型案例： microsoft/ai-discovery-agent

手法： 把恶意 payload 藏在 branch name，再插进 shell 执行。

盲点： 很多团队根本没把 branch name 当不可信输入！

4. 文件名注入

典型案例： DataDog/datadog-iac-scanner

手法： 在文件名里塞 shell 命令，让 workflow 自己展开执行。

常见于： 把 diff/文件列表直接拼进 Bash 的写法。

5. Prompt injection 攻击 LLM reviewer

典型案例： ambient-code/platform

手法： 把恶意指令写进 CLAUDE.md / issue / PR 内容，让 AI 带权限执行。

新维度： 这已经不是"脚本注入"，而是**"把 agent 当跳板"**。

---

三、为什么 AI 编程团队尤其危险？

很多团队的默认路线，正好把风险叠起来：

做法	风险
用 claude-code-action / codex-action 自动 review	Agent 读取不可信输入
用 issue_comment / slash command 触发 Agent	任何人都能触发
让 Agent 读 repo 里的 CLAUDE.md、技能文件	配置文件可能被投毒
给 workflow 开评论、打标签、提 PR 权限	权限过大
GITHUB_TOKEN 默认权限开得大	爆炸半径大

这些设计单看都"能跑"，但一组合，风险上一个量级。

---

四、7 条加固清单（可直接落地）

✅ 1. GITHUB_TOKEN 默认权限收成最小值

permissions: {}  # 默认无权限

jobs:
  review:
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false  # 关键！

✅ 2. 拆分 pull_request_target 的使用场景

• 执行 untrusted code： 用 pull_request，只读、不给 secrets
• 评论/打标签： 如果必须用 pull_request_target，只做 metadata，不执行 fork 代码

✅ 3. 把所有输入都当不可信输入

❌ 不安全：

- run: echo "${{ github.event.pull_request.title }}"

✅ 安全：

- name: Check PR title safely
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: |
    if [[ "$PR_TITLE" =~ ^release: ]]; then
      echo "release PR"
    fi

✅ 4. comment trigger 先做身份校验

if: >
  github.event.issue.pull_request &&
  contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), 
           github.event.comment.author_association)

✅ 5. LLM workflow 权限分层

层级	权限	触发条件
只读分析	读 issue/PR、产出摘要	可默认开
评论/标签	给建议标签、评论结论	限成员触发
写代码/发 PR	写权限	必须人工审批

✅ 6. 优先 OIDC + 短期凭证

permissions:
  id-token: write
  contents: read

不要用长期 PAT，用 OIDC 换短时凭证。

✅ 7. 把 workflow 当高价值代码治理

• .github/workflows/ 加进 CODEOWNERS
• 第三方 action 能 pin SHA 的先 pin
• 打开 rulesets / branch protection
• 给 workflow 单独做 code scanning

---

五、明天就能做的 3 件事

第一步：全仓搜高危模式

# 搜索这些关键词
pull_request_target
issue_comment
workflow_run
github.event.comment.body
github.event.pull_request.title
allowed_non_write_users
contents: write

第二步：把默认权限降下来

组织/仓库层级设置 restricted / read-only，再按 job 补权限。

第三步：AI workflow 重新分级

把现有的 AI workflow 分成三类，先拆开最危险的组合。

---

六、结论

2026 年 AI 编程的真正分水岭：

不是你能不能把 AI 接进 GitHub，而是你能不能在接进去之前，把 guardrails 先搭好。

hackerbot-claw 的出现是一个信号：攻击者也在用 AI Agent 自动化攻击。

当攻击自动化遇上防御自动化，谁能先建立安全边界，谁就能在这个新战场上占据主动。

---

参考来源：

• StepSecurity 披露报告 (2026-03-01)
• Datadog 工程团队分析
• GitHub Security Lab 安全指南
• GitHub Well-Architected 2026

---

本文基于公开安全报告整理，旨在提升社区安全意识。