GitHub Actions の pull_request_target が12月2日から公開リポジトリで既定ブロックに？確認と準備

公開リポジトリで GitHub Actions を使っている方向けの記事です。フォークからの Pull Request に、ラベルを付けたりコメントを返したりする自動化を持っている方は、特に確認してください。

この記事は、GitHub の changelog（2026年11月2日）と公式ドキュメント「Securely using pull_request_target」「Control workflow execution」をもとにしています（2026年11月3日に確認）。日程や範囲は更新されることがあります（当初の予定は11月2日でしたが、12月2日に変更されました）。作業の前に、公式の最新を確かめてください。

何が変わるのか：日程と対象

まず、自分のリポジトリが対象かを確かめる

pull_request_target を使うワークフローが無ければ、影響はありません。リポジトリの中を検索します。

# リポジトリの直下で実行する
grep -rn "pull_request_target" .github/workflows/

見つかったら、次の2点を見ます。

公式ドキュメントによると、いまは評価の状態で、ワークフローは動き続けます。リポジトリまたは組織の「Settings」→「Actions」→「Policies」にあるポリシーの Insights で、強制されたらブロックされる実行を確認できます。11月9日の前に、ここを一度見ておくと、試験的な強制の時間に慌てずに済みます。

影響があるとき：3つの選び方

許可するとき

許可は、Actions のイベントポリシーで行います。公式ドキュメントでは、ポリシーに名前を付け、対象のワークフロー・組織・リポジトリを指定し、許可するイベントに pull_request_target を入れる形です。特定のワークフローだけを許可する指定もできるので、リポジトリ全体を広く許すより、必要なファイルだけに絞るほうが安全です。設定の手順は、公式ドキュメント「Control workflow execution」で確かめてください（画面の項目名は変わることがあります）。

なぜブロックするのか：pull_request_target の危険

pull_request_target は、基準のリポジトリの権限（読み書きできるトークンとシークレット）で動く、信頼度の高いトリガーです。フォークの PR に対して、ラベルを付けたり、状態を返したりするために作られています。

既定では、ワークフローのファイルも、ref を指定しない actions/checkout も、PR ではなく基準のリポジトリの既定のブランチから取得されます。つまり、フォーク側のコードは動きません。ここまでは安全です。

危険になるのは、PR のコードを取得して動かしたときです。公式ドキュメントはこれを「pwn request」と呼んでいます。

取得しただけでは無害ですが、そのあとに npm install、npm run build、Makefile、設定ファイルなどを動かした時点で、攻撃者のコードが基準のリポジトリのシークレットとトークンを使って動きます。公式ドキュメントは、issue_comment や workflow_run でも、フォーク由来のコードを取得して動かせば同じ問題が起きると説明しています。

# 危険な形の例（真似しないでください）
on: pull_request_target
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@（固定した版）
        with:
          ref: ${{ github.event.pull_request.head.sha }}   # PR のコードを取得している
      - run: npm install && npm test                       # 攻撃者のコードが動く

許可するなら、安全な使い方を守る

公式ドキュメントの要点は、次のとおりです。

PR のコードを取得しない、ラベル付けだけの例です。

on:
  pull_request_target:
    types: [opened]
permissions:
  pull-requests: write
jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      # PR のコードは取得しない。番号を使ってラベルを付けるだけ（ラベルは先に作っておく）
      - run: gh pr edit "$PR_NUMBER" --repo "$GH_REPO" --add-label "needs-review"
        env:
          GH_TOKEN: ${{ github.token }}
          GH_REPO: ${{ github.repository }}
          PR_NUMBER: ${{ github.event.pull_request.number }}

run の中に ${{ ... }} を直接書かず、環境変数を経由して渡すのも大切です。PR の題名のような、攻撃者が書き換えられる文字列を run に直接埋め込むと、コマンドが注入されるおそれがあるからです。

actions/checkout の保護との関係

actions/checkout には、フォークの PR の先頭のコミットの取得を防ぐ既定の保護があります。意図してその取得をするなら、allow-unsafe-pr-checkout: true を指定すると取得できますが、公式ドキュメントは取得したコードを決して実行しないと確かめた後にだけ使うよう求めています。なお、無関係な第三者のリポジトリのコード、git fetch や gh pr checkout による取得、成果物の実行は、この保護の対象外です。

よくある質問

Q. 非公開のリポジトリでも、対応が必要ですか。

A. 必要ありません。この既定のブロックは、公開リポジトリだけが対象です。非公開・内部のリポジトリは影響を受けません。

Q. 11月9日の試験的な強制の間に、何が起こりますか。

A. ブロックの対象の pull_request_target の実行が、エラーの注釈つきの失敗になり、ワークフローは動きません。終わると評価の状態に戻り、ワークフローは警告つきで動きます。その時間にたまたま来た PR への自動化が動かないだけで、リポジトリが壊れるわけではありません。

Q. 何もしないと、どうなりますか。

A. pull_request_target を使っていなければ、何も起きません。使っていて許可もしなければ、12月2日からそのワークフローが動かなくなります。

まとめ

GitHub Actions の基本は GitHub Actions とは、外部のアクションを固定する仕組みは GitHub Actions のロックファイルで整理しています。CI の設定が攻撃の入口になる例は VS Code の悪意あるリポジトリでも扱っています。

参考にした情報

• GitHub Changelog：pull_request_target blocked by default December 2（2026年11月2日）
• GitHub Docs：Securely using pull_request_target
• GitHub Docs：Control workflow execution