pull_request_targetが12月2日から既定ブロック【2026年11月】

公開リポジトリで、フォークからのプルリクエストに反応する GitHub Actions のワークフローを動かしている人は要注意の発表です。

2026年11月2日（米国時間）、GitHub は 2026年12月2日から、公開リポジトリの pull_request_target イベントを既定でブロックすると GitHub Changelog で発表しました。当初は11月2日に始める予定でしたが、1か月延びた形です。

pull_request_target blocked by default December 2

その前に、11月9日と11月16日には2時間だけ試験的にブロックする「ブラウンアウト」も予定されています。日本時間ではどちらも翌日の深夜1時〜3時です。「便利だが危ないトリガー」を、使う人が明示的に選ぶものに変える——という位置づけの変更です。

pull_request_target の既定ブロックとは？一言でまとめると

公開リポジトリで pull_request_target から起動するワークフローを、許可していない限り動かさないという GitHub 側の既定ルールです。GitHub が9月に一般提供した「ワークフロー実行保護（workflow execution protections）」の仕組みで入ります。

ブロックされた実行は、エラーの注釈付きで失敗した実行として残り、ワークフローの中身は動きません。GitHub Docs には、ポリシーで止められたときに「Event ‘〇〇’ is not allowed to trigger Actions workflows.」という形のエラーが出る例が載っています。

いつから？12月2日の本番と11月のブラウンアウト

スケジュールは次のとおりです。ブラウンアウトの時間は UTC なので、日本時間では翌日の未明になります。

ブラウンアウトの間に対象のワークフローが起動すると、失敗した実行が作られ、ワークフローは動きません。時間が過ぎると既定ルールは evaluate モードに戻り、警告付きで動く状態に戻ります。12月2日に何時から適用されるかは、公式発表では示されていません。

GitHub は、1回目のブラウンアウト（11月9日）より前に Insights で影響を確認するよう呼びかけています。

影響を受けるリポジトリ・受けないリポジトリ

影響を受けるのは、公開リポジトリで、on: pull_request_target を使うワークフローがあり、それを許可するイベントポリシーがない場合です。

pull_request_target は、フォークからのプルリクエストにラベルを付ける・トリアージする・認証が必要なステータスチェックを書き込むといった自動化に使われてきたトリガーです（GitHub Docs）。OSS で「外部の人の PR にボットが自動でラベルやコメントを付ける」仕組みを入れているなら、まず当てはまらないか確認しましょう。

手元で探すなら、リポジトリの .github/workflows/ の中で pull_request_target を検索するのが手早い方法です。

なぜブロックするのか：「pwn request」の危険

pull_request_target で動くワークフローは、ベースリポジトリの GITHUB_TOKEN（書き込みできるトークン）とシークレットを使える、権限の強いトリガーです。

GitHub Docs によると、pull_request_target 自体は、既定ではデフォルトブランチのワークフローとコードだけを動かすので安全です。問題になるのは、作者がわざわざフォークのコードを取り込んで実行する場合です。

Docs が「危険な例」として挙げるのは、actions/checkout で PR の head を取り込み、その後に make test などを実行する形です。攻撃者は、Makefile やビルドスクリプト、依存パッケージに悪意のあるコマンドを仕込んだ PR をフォークから出すだけで、ベースリポジトリのシークレットとトークンを使ってコマンドを実行できてしまいます。

この手口は 「pwn request」 と呼ばれ、GitHub は複数のサプライチェーン攻撃の原因になってきたと説明しています。9月の Changelog でも、pull_request_target の脆弱性はActions のワークフローで最も多く悪用される脆弱性の一つとされています。

利用者がすべき対応：3つの選択肢

GitHub Docs は、影響を受けるワークフローごとに次のどれかを選ぶよう勧めています。

① まず Insights で影響を確認する

既定ルールは今 evaluate モードなので、「本格適用されたら止まる実行」を Policy insights で確認できます。Docs によると、Policy insights はリポジトリ・Organization・Enterprise のサイドバーの Actions の「Policies」のすぐ下にあります。

② 不要なら pull_request に切り替える

シークレットを使わないなら、pull_request に置き換えるのが Docs の第一の推奨です。pull_request は pull_request_target と同じタイミングで起動し、フォークからの PR でも安全に動くよう制限がかかっています。

③ どうしても必要なら、イベントポリシーで明示的に許可する

使い続けるなら、Actions のイベントポリシーで pull_request_target を許可します。Docs の手順の要点は次のとおりです。

1. リポジトリ（または Organization）の Settings → 左のサイドバーの Actions → Policies を開く（Enterprise は Policies タブ → Actions → Policies）
2. 新しいポリシーを作り、名前・適用状態・対象を決める
3. イベントルールで pull_request_target を許可する
4. ワークフローファイル指定で、許可するワークフローだけに絞る

リポジトリ全体で許可するより、必要なワークフローのファイルだけを許可するのが Changelog の勧める使い方です。ポリシーを設定できるのは、リポジトリ管理者・Organization オーナー・Enterprise オーナーです。REST API でもポリシーを管理できます。

ブロックのままでよいなら、何もしなければ12月2日から既定ルールが効きます。

許可する場合の注意点

Docs は「pull_request_target は必要なときだけ許可し、信頼できない PR のコードをシークレット付きでチェックアウト・ビルド・実行しないこと」と警告しています。許可する場合に勧められている強化策は次のとおりです。

• 権限を最小にする: GITHUB_TOKEN の権限を絞り、必要なシークレットだけを使う
• キャッシュは読み取り専用: pull_request_target のワークフローは、デフォルトブランチのキャッシュを復元はできるが作成・上書きはできない（キャッシュ汚染の対策）
• セルフホストランナーに注意: 内部のリソースから切り離し、実行ごとに使い捨てる
• CodeQL で Actions を検査: コマンドインジェクションなどの脆弱性も見つける

また、actions/checkout の v7 は、pull_request_target と workflow_run で、フォークの PR のコードを既定ではチェックアウトしなくなりました（公式リポジトリの README）。どうしても必要な場合は allow-unsafe-pr-checkout: true を指定しますが、Docs は「チェックアウトしたコードを絶対に実行しないと確認してから」としています。名前があえて目立つようにしてあり、コードレビューで見つけやすくする狙いです。

なお、Docs は issue_comment や workflow_run でも、フォークのコードを取り込んで実行すれば同じ危険があると注意しています。今回のブロックは pull_request_target だけが対象なので、他のトリガーも見直しておくと安心です。

これまでの流れ：6月のプレビューから今回まで

今回の既定ブロックは、GitHub が2026年に進めている Actions のセキュリティ強化の一部です。

同じ「Policies」には、action をコミットに固定するロックファイルを必須にする「Require lockfile」も入っています。ロックファイルの仕組みは、プレビュー時の記事で解説しています。

あわせて読みたい

GitHub Actionsにロックファイル、依存をコミットで固定【2026年10月】

IT Picks的な所感

pull_request_target の危険は以前から GitHub Security Lab などが注意してきましたが、「危ない使い方をしないでください」という呼びかけだけでは防ぎきれなかった——というのが今回の背景だと考えています。既定でブロックし、使う人に明示的な許可を求める形は、OSS のサプライチェーン攻撃を減らすうえで筋のよい変更だと評価しています。

一方で、ラベル付けやコメント投稿のボットなど、正しく使っているワークフローも一律に止まります。メンテナーが少ない OSS では、通知を見落としてある日から自動化が動かなくなることも起こりそうです。まずは11月10日未明の1回目のブラウンアウトの前に Insights を確認しておくのが現実的でしょう。

actions/checkout の既定動作の変更、キャッシュの読み取り専用化、ロックファイルと、GitHub は Actions の「安全な既定値」を一気に揃えてきています。GitHub Universe で発表された Copilot 関連の新機能と合わせて、開発基盤としての GitHub の変化は今後も追っていきたいところです。

あわせて読みたい

GitHub Universe、Copilot新機能まとめ【2026年10月】

まとめ

pull_request_target の既定ブロックのポイントをまとめます。

• 発表日：2026年11月2日（GitHub Changelog）
• 本格適用：2026年12月2日（当初は11月2日の予定）
• ブラウンアウト：日本時間 11月10日・11月17日の 1:00–3:00
• 対象：公開リポジトリ（Free / Team / Enterprise Cloud）。非公開・internal・GHES は対象外
• 理由：フォークのコードがシークレット付きで動く「pwn request」を防ぐため
• 対応：Insights で確認 → pull_request に移す、またはイベントポリシーでワークフローごとに許可

公開リポジトリを運用しているなら、まずは .github/workflows/ で pull_request_target を検索し、Policy insights で止まる予定の実行がないか確かめておきましょう。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。