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
危险模式：
yaml
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 默认权限收成最小值
yaml
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. 把所有输入都当不可信输入
❌ 不安全：
yaml
- run: echo "${{ github.event.pull_request.title }}"✅ 安全：
yaml
- 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 先做身份校验
yaml
if: >
github.event.issue.pull_request &&
contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'),
github.event.comment.author_association)✅ 5. LLM workflow 权限分层
| 层级 | 权限 | 触发条件 |
|---|---|---|
| 只读分析 | 读 issue/PR、产出摘要 | 可默认开 |
| 评论/标签 | 给建议标签、评论结论 | 限成员触发 |
| 写代码/发 PR | 写权限 | 必须人工审批 |
✅ 6. 优先 OIDC + 短期凭证
yaml
permissions:
id-token: write
contents: read不要用长期 PAT，用 OIDC 换短时凭证。
✅ 7. 把 workflow 当高价值代码治理
.github/workflows/加进 CODEOWNERS- 第三方 action 能 pin SHA 的先 pin
- 打开 rulesets / branch protection
- 给 workflow 单独做 code scanning
五、明天就能做的 3 件事
第一步：全仓搜高危模式
bash
# 搜索这些关键词
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
本文基于公开安全报告整理，旨在提升社区安全意识。