GitHub Actionsで最も多い設定ミスの一つが、今回の更新でデフォルトで止まるようになりました。
この記事では、actions/checkout v7のセキュリティ強化と、開発者が今すぐ確認すべき点を整理します。
この記事でわかること
- pwn requestとは何か、なぜ危険なのか
- v7でブロックされるチェックアウトパターン
- 既存ワークフローへの影響とオプトアウト方法
- 今回の変更で防げないリスク
pwn requestがサプライチェーン攻撃の入口になっていた
GitHub Actionsのpull_request_targetイベントは、フォーク(他者のリポジトリから分岐したコピー)由来のプルリクエストに対しても、ベースリポジトリのGITHUB_TOKENやシークレット、デフォルトブランチのキャッシュへアクセスできます。ラベル付けやステータスチェックの投稿など、権限が必要な自動化のために用意されたトリガーです。
問題は、この権限の高い文脈でフォークのPRコードをチェックアウトし、そのまま実行してしまうパターンです。攻撃者はフォークから悪意あるMakefileやビルドスクリプト、依存パッケージを含むPRを送り、ベースリポジトリのシークレットを奪います。この手口は「pwn request(パウンリクエスト)」と呼ばれ、GitHub Security Labが2020年から警告を続けてきた脆弱性です。
実際に被害が出ています。Nxではpull_request_targetの権限昇格を悪用し、npm公開トークンが奪われました。PostHogではレビュアー自動割り当て用のワークフローがpull_request_targetに切り替わった74日後、フォークPR経由でボットのPATが漏えいし、8つのnpmパッケージが改ざんされました(参考)。どちらもビルドパイプライン以外の「便利な自動化」が入口になった点が共通しています。
actions/checkout v7が拒否するパターン
2026年6月18日、GitHubはactions/checkout v7を一般提供し、危険なフォークPRチェックアウトをデフォルトで拒否するようになりました(参考)。対象はpull_request_targetトリガーと、workflow_run.eventがpull_request系のworkflow_runトリガーです。同一リポジトリ内のPRや、通常のpull_requestイベントは変更ありません。
ブロックされるのは、フォーク由来のPRに対して次のいずれかを指定した場合です。
repository:にフォークのリポジトリ名を指定するref:にrefs/pull/番号/headやrefs/pull/番号/mergeを指定するref:にフォークPRのhead SHAやmergeコミットSHAを指定する
典型的な危険な記述は次のとおりです。
ref: ${{ github.event.pull_request.head.sha }}
ref: refs/pull/${{ github.event.pull_request.number }}/merge
repository: ${{ github.event.pull_request.head.repo.full_name }}
v7ではこれらの指定があるとチェックアウトが失敗し、後続ステップで攻撃者のコードが実行される経路を断ちます。v7はESMへの移行や依存パッケージのセキュリティ修正も含みます。
既存バージョンへのバックポートと確認手順
2026年7月16日、GitHubはこの保護を現在サポート中の全メジャーバージョンにバックポートします。actions/checkout@v4のようにメジャータグで固定しているワークフローは、タグを更新しなくても自動で保護を受けます。一方、特定のSHAやマイナー・パッチバージョンにピン留めしたワークフローは対象外です。Dependabotや手動アップグレードで追従が必要です。
まず自リポジトリのワークフローを検索し、pull_request_targetとactions/checkoutの組み合わせがないか確認してください。フォークPRのheadやmergeをrefに渡している箇所があれば、v7適用後にビルドが失敗します。意図的な利用であれば、次のようにオプトアウトできます。
- uses: actions/checkout@v7
with:
ref: ${{ github.event.pull_request.head.sha }}
allow-unsafe-pr-checkout: true
フラグ名はallow-unsafe-pr-checkoutと、コードレビューや静的解析で目立つよう意図的に付けられています。設定前にGitHub公式の安全利用ガイドを読み、チェックアウトしたコードを実行しない設計かを確認してください。カバレッジレポート生成のようにフォークコードの実行が本当に必要な場合は、pull_requestとpull_request_targetを分離する二段構成の検討が推奨されています。
今回の変更で防げないリスク
actions/checkoutの保護はフォークPRのhead・mergeコミット取得に限定されます。git fetchやgh pr checkoutでコードを取得して実行する手口、issue_commentトリガーでの同様のパターン、無関係な第三者リポジトリのチェックアウトはブロック対象外です。GitHubも「追加イベントの強化は今後検討する」と述べています。
セキュリティチームは、checkout以外の経路で未信頼コードが権限の高いワークフローに入り込んでいないかも点検する必要があります。共有キャッシュへの書き込み、パッケージのライフサイクルスクリプト実行、アーティファクトの復元など、フォーク由来データを信頼済みとして扱う箇所が残っていないかを見直してください。
GitHub Actionsを使う開発者にとって、今回の更新は「知っていれば防げた」類の事故をプラットフォーム側で止める動きです。ワークフローのピン留め方式を確認し、意図しないオプトアウトが紛れ込んでいないか、今日のうちにリポジトリを一度見直す価値があります。