actions/checkout v7、pull_request_targetでのフォークコードチェックアウトを拒否する安全側デフォルトに

Safer pull_request_target defaults for GitHub Actions checkout

元記事は一次情報へのリンクです元記事を読む

5行でつかむ要点

GitHubは2026年6月18日、actions/checkout v7で「pull_request_target」イベント使用時に、フォークのプルリクエストコードをデフォルトで拒否する安全機能を追加したと発表した。

repositoryがフォークを指し、refがフォークのHEADやマージコミットに解決される場合、チェックアウトが失敗するようになる。同一リポジトリ内のPRは影響を受けない。

actions/checkout@v4など浮動タグを使うワークフローにも、2026年7月16日の逆移植(バックポート)でこの保護が自動適用される。

pull_request_targetを使った自動化ワークフローを持つチームは、意図せずこの保護に引っかかっていないか一度点検する価値がある。

コードスキャン専用ジョブなど意図的にフォークコードをチェックアウトしている少数派の運用がある場合、逆移植の適用前に動作確認をしておいたほうがよい。

変更の中身

GitHub Actionsのチェックアウト処理を担うactions/checkoutが、v7で挙動を変えた。pull_request_targetイベントを使うワークフローで、チェックアウト対象のrepositoryがフォークを指し、かつrefがフォークPRのHEADやマージコミットに解決される場合、処理そのものを失敗させるようになる。同一リポジトリ内で完結するPRのワークフローには影響がない。

なぜここが長年狙われてきたのか

pull_request_targetは、フォークから送られたPRをトリガーにしながら、ベースリポジトリ側の強力な権限(シークレットへのアクセスなど)でジョブを実行できる特殊なイベントだ。便利さと引き換えに、外部から届いた未レビューのコードをその強い権限のまま動かしてしまう設定ミスが後を絶たず、「pwn request」と呼ばれるこの攻撃パターンは、過去にも複数のオープンソースプロジェクトでシークレット漏えいの原因になってきた。原因の多くは悪意ではなく、pull_requestとの挙動の違いを把握しないままワークフロー定義をコピーしてしまうことにある。

初期値を変えるという選択

今回の対応が興味深いのは、ドキュメントで注意喚起するのではなく、ツール自体の既定動作を「危険な組み合わせは止める」方向に倒した点だ。セキュリティ対策では、人間の注意力に頼る運用は時間が経つほど形骸化しやすいというのが定説であり、ツール側のデフォルトを安全に倒すアプローチの方が効果が長続きしやすい。

移行時の注意点

2026年7月16日の逆移植により、actions/checkout@v4のようにバージョンを固定せず浮動タグで参照しているワークフローにも、同じ保護が自動的に波及する。意図してフォークのコードをチェックアウトしている数少ないワークフロー(コードスキャン専用ジョブなど)を運用している場合は、事前に動作確認をしておいた方がよい。具体的な設定変更手順はGitHub Changelogの発表(https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/)にまとまっている。