pull_request_target 与 PR Head 检出：AI Agent 工作流提示注入攻击向量（Vector D）深度解析

pull_request_target 与 PR Head 检出AI Agent 工作流提示注入攻击向量Vector D深度解析【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib导读本文基于 anomalib 仓库内agentic-actions-auditor技能库的 Vector D 参考文档深入剖析一类针对 CI/CD 中 AI AgentClaude Code Action、Gemini CLI、OpenAI Codex 等的高危提示注入攻击当工作流使用pull_request_target触发并检出 PR 的 head 提交时攻击者的代码将携带仓库机密Secrets进入 AI Agent 的执行上下文。读完本文你将掌握该向量的完整数据流、两步检测法、漏洞模式示例、误报排除规则与可落地的加固修复方案。攻击向量概述可信执行上下文 × 不可信代码pull_request_target是 GitHub Actions 中一个特殊且高危的触发事件它运行的是基础分支base branch上的工作流定义而非来自 Fork 的 PR 分支定义。这意味着工作流拥有仓库机密的访问权限同时却能被任何外部贡献者通过提交 Pull Request 触发。当工作流在pull_request_target上下文中执行actions/checkout并显式检出 PR 的 head 提交${{ github.event.pull_request.head.sha }}等时就形成了 Vector D 的核心条件可信执行上下文携带 Secrets 攻击者控制的代码PR headAI Agent 在拥有仓库 Secrets 的进程里读取的是攻击者修改过的文件代码注释、README、配置文件、测试文件、文档等。攻击者在这些文件中埋入提示注入载荷AI 一旦读取并听从就会以持有 Secrets 的 Agent 身份执行攻击者指令。适用 Action凡是从工作目录读文件的 AI 都有风险该向量的关键前提是AI Action 会从检出checked-out的工作目录读取文件。因此只要被调用的 AI 工具具备文件系统读取能力就适用此向量。文档给出的适用性对照如下Action适用性说明Claude Code Action适用已确认PoC 18 已验证会读取检出的工作目录文件Gemini CLI适用若配合pull_request_target使用文件系统读取行为相同OpenAI Codex适用会读取工作目录文件用于代码分析GitHub AI Inference可能较少见但当提示词指示模型从磁盘读取文件内容时同样适用攻击者将提示注入载荷prompt injection payload嵌入代码注释、README 文件、配置文件或任何 AI 在评审过程中可能读取的文件中——AI 评审的正是这些文件本身因此注入面天然存在。触发事件为什么是 pull_request_targetpull_request_target工作流从基础分支运行拥有仓库 Secrets但由外部 Pull Request 激活。这一信任与不可信输入的组合正是漏洞根源。普通pull_request来自 Fork 的 PR不会获得仓库 Secrets因此从 Secrets 窃取角度看是安全的虽然代码执行在其他场景下仍是隐患。这一点在技能库的 foundations.md 中有完整的触发事件风险对照表pull_request_target暴露的攻击者可控数据包括 PR 标题、正文、head ref 与 head SHA且运行于带 Secrets 的基础分支上下文风险等级最高。数据流从攻击者 PR 到 AI 执行上下文Attacker opens fork PR - pull_request_target runs workflow from base branch (has secrets) - actions/checkout with ref: PR head fetches attackers code to disk - AI agent reads files from working directory - Attacker-modified code processed with access to repository secrets这条链路的关键点在foundations.md的三条数据流模型Path 1 直接表达式插值、Path 2 env 变量中转、Path 3 运行时拉取之外构成第四种形态攻击者输入经由文件系统这一物理媒介进入 AI 上下文。与 Vector CCLI 数据拉取类似工作流 YAML 本身可能看起来非常干净——没有任何${{ github.event.* }}出现在 prompt 字段中因为恶意内容存在于磁盘文件中而非事件上下文字符串。两步检测法两个条件必须同时成立检测 Vector D 必须遵循两步走缺一不可第一步检查on:块中是否存在pull_request_target触发事件第二步查找检出 PR head 的 checkout 步骤命中以下任一模式即触发告警actions/checkout任意版本带ref:且取值为以下之一${{ github.event.pull_request.head.sha }}${{ github.event.pull_request.head.ref }}${{ github.head_ref }}run:步骤中的git checkout/git fetch命令拉取 PR head 分支或提交pull_request_target单独出现不是漏洞。没有检出 PR headAI Agent 只会看到可信的基础分支代码是检出这一步让代码落入攻击者控制。这就是为何该向量在技能库的 SKILL.md 中被标记为 PR Target Checkout快速检查pull_request_target触发 带指向 PR head 的ref:的 checkout。排查位置清单工作流文件顶部的on:块查找pull_request_target所有 job 中的所有steps:查找带ref:或with.ref字段的actions/checkout步骤run:步骤中的git checkout、git fetch、git switch命令确认是否引用 PR head注意不带ref:字段的actions/checkout默认检出基础分支在pull_request_target下是安全的从技能库的 cross-file-resolution.md 可知这类 AI Agent 还可能隐藏在被调用的复合动作composite action或可复用工作流reusable workflow中——审计时应沿uses:引用做一层深度解析并追踪with:→inputs.*→ prompt 字段的输入映射链路。为什么危险Secrets 与攻击者文件的结合AI Agent 运行时所处的执行上下文携带基础分支 Secrets可能包括具备写权限的GITHUB_TOKEN部署密钥deployment keysAPI 凭证仓库中配置的任何其他 Secrets但它处理的却是攻击者修改过的文件。攻击者可以在 AI 大概率会读取的任何文件中埋入提示注入载荷代码注释、README、配置文件、测试文件、文档。一旦注入成功AI 将带着这些 Secrets 执行攻击者指令。foundations.md还补充了一个易被忽略的机制env:块中的${{ }}表达式在步骤运行之前就被求值步骤只能看到解析后的字符串值。这意味着即使审计人员未在 prompt 字段中发现表达式攻击者内容也可能经 env 变量中转进入 AI 上下文即 Vector A与本向量叠加放大风险。漏洞模式示例来自 PoC 18以下 YAML 来自 PoC 18frankbria/ralph-claude-code完整展示了两个步骤的配合on: pull_request_target: # Step 1: Runs in base branch context types: [opened, synchronize] jobs: claude-review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: ref: ${{ github.event.pull_request.head.sha }} # Step 2: Checks out ATTACKERs code - uses: anthropics/claude-code-actionv1 with: prompt: | Please review this pull request and provide feedback # AI reads attacker-modified files from disk with base repo secrets availableStep 1 使工作流在基础分支上下文运行获得 SecretsStep 2 把攻击者的代码检出到磁盘随后 Claude Code Action 以请评审这个 PR的善意提示启动但实际读取的代码、README 与配置文件中都可能是攻击者精心构造的注入指令。误报排除五类常见安全场景为避免安全团队被误报淹没文档明确列出以下安全场景最常被误报pull_request_target但未检出 PR headAI 只能看到可信的基础分支代码——这是最常见的误报来源pull_request_targetactions/checkout但无ref:字段默认检出基础分支安全普通pull_request触发 检出 PR headFork 的 PR 不获得 Secrets无法实现机密窃取虽然 runner 上的代码执行仍是独立隐患pull_request_target仅用于打标签、评论或状态检查且没有在代码上运行 AI Agent无 AI 处理即无提示注入面pull_request_target的ref:显式指向基础分支如ref: ${{ github.event.pull_request.base.sha }}检出的是可信代码修复与加固建议结合技能库 action-profiles.md 中各 Action 的安全配置基线修复方向分为两类根治检出问题直接消除向量 D优先使用pull_request触发 手动批准后运行或对来自 Fork 的 PR 不检出 head默认检出基础分支若必须评审 PR head先人工审核或使用隔离环境确保 AI Agent 与仓库 Secrets 不在同一执行上下文在检出后增加内容消毒步骤去除 HTML 注释、不可见字符、Markdown 图片 alt 文本等隐藏注入载体这与 Claude Code Action 内置的 prompt 清洗逻辑思路一致纵深防御降低注入成功后的影响Action推荐加固Claude Code Action用--allowedTools Bash(npm test:*) Bash(git diff:*)替代Bash(*)保持show_full_output: false不使用allowed_non_write_users: *OpenAI Codexsandbox: workspace-write默认或read-onlysafety-strategy: drop-sudoallow-users用显式用户列表Gemini CLIsettings JSON 中配置sandbox: true移除--yolotools.core中不放run_shell_command(echo)等可扩展命令通用最小化permissions:如contents: readAI 输出绝不经eval/exec/未加引号的$()消费Vector G需要特别强调从本仓库.github/workflows/的实际扫描结果看现有的auto-approve.yml等文件虽引用了github.event.pull_request.head.sha但当前仓库工作流中并未发现pull_request_target 检出 PR head 的组合也未发现 AI Action 调用——即本仓库当前不构成 Vector D 的实际利用面本文所分析的场景适用于将来或他处引入 AI Agent 工作流时的防御基线。结语把检出 PR head当作代码执行边界来审查Vector D 的本质是信任边界混淆pull_request_target提供了可信执行上下文Secrets而检出 PR head 把不可信代码引入该上下文。审计 CI/CD 中的 AI Agent 集成时应把是否检出攻击者控制的代码视为与是否执行攻击者脚本同级的代码执行边界问题。掌握本文的两步检测法与误报排除规则后即可在引入 Claude Code Action、Gemini CLI 或 OpenAI Codex 等工作流时快速识别并阻断这一高危注入路径。【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考