GitHubが、actions/checkout の最新版で、よくある「pwn request」攻撃パターンをブロックするようにしました。
ざっくり言うと、権限の強いワークフローの中で、信用できないforkのPull Requestコードをうっかり実行してしまう事故を減らすための変更です。
これ、地味に見えてかなり大事です。CI/CDやGitHub Actionsを触っている人なら「まあ注意していれば大丈夫でしょ」と思いがちですが、攻撃者はその“うっかり”を狙ってきます。しかも pull_request_target は、仕組みを理解していないと本当に危ない。
actions/checkout v7 が、fork由来の危険なPull Requestのチェックアウトをデフォルトで拒否pull_request_target と、条件付きで workflow_runallow-unsafe-pr-checkout: true で回避もできる今回の更新は、GitHub公式の actions/checkout が、forkされたPull Requestのコードを安全でない文脈では読まないようにする、というものです。
適用は2026年6月18日からで、2026年7月16日には現在サポートされている主要バージョンにもバックポートされる予定だとされています。
ここで出てくる actions/checkout は、GitHub Actionsの中でリポジトリの中身を作業用マシンに取り出すための定番アクションです。
要するに「このワークフロー、どのコードを見に行くのか」を決める部品ですね。
問題は、その部品が「信頼していないPull Requestの中身」まで素通りで持ってきてしまうと、そのまま悪意あるコードを実行する流れになることです。
pull_request_target が危ない理由今回のニュースの中心にあるのが pull_request_target です。
これはPull Requestが開かれたときや再オープンされたとき、あるいは更新されたときに自動実行されるワークフローです。
ただし、ここがややこしい。pull_request_target はベースリポジトリの default branch の文脈で動くので、GITHUB_TOKEN や secrets を持ったまま動いてしまいます。
この GITHUB_TOKEN は、GitHub Actionsが使う認証用トークンで、権限設定によっては読み書きできてしまいます。secrets は、APIキーやパスワードのような機密情報ですね。
つまり、攻撃者がforkから悪意あるPull Requestを送り込み、ワークフローがそのコードをチェックアウトして実行してしまうと、トークンや秘密情報を抜かれる可能性があるわけです。
GitHub自身も、これが cache poisoning や、意図しない書き込み権限・secretへのアクセスにつながると注意しています。
個人的には、ここはGitHub Actionsの“分かりにくい危険ポイント”の代表格だと思います。
名前だけ見ると「Pull Request向けで安全そう」に見えるのに、実際はかなり権限が強い。初見殺し感があります。
今回 actions/checkout v7 が拒否するのは、forkのPull Requestに対して次のようなケースです。
repository が fork のPull Request先を指しているref が refs/pull/番号/head または refs/pull/番号/merge に一致するref が fork の head commit や merge commit のSHAに解決される要するに、fork由来の未レビューコードを、権限の強いワークフローで取り込む典型的な流れをブロックするわけです。
ただし完全な封鎖ではありません。
ワークフロー作者が明示的に allow-unsafe-pr-checkout: true を設定すれば、従来どおり危険なチェックアウトも可能です。つまり、GitHubは「絶対禁止」ではなく、危険な道に入るなら自分で覚悟して進んでくださいという設計にした、という見方ができます。
このバランスは現実的だと思います。
現場では例外対応が必要なこともあるので、全面禁止にすると逆に運用が止まる。でも、デフォルトで危険を塞ぐのは大事です。
Socketのコメントでも触れられていましたが、今回の防御は**actions/checkout を通したチェックアウトだけ**が対象です。
つまり、他の手段で untrusted code を持ち込むケースまでは止めません。
たとえば、
issue_comment など別のイベント経由git コマンドを直接使うrepository: に指定するこういうケースは、今回の変更の守備範囲外です。
ここはかなり重要です。
「GitHubが対策したから大丈夫」と思うと危ない。実際には、権限のあるワークフローで信用できないコードを実行すること自体がリスクで、今回の修正はその入口を一つ狭めただけです。
「pwn request」という呼び方は少し物騒ですが、言いたいことは単純です。
Pull Requestを悪用して、相手のCI環境や権限を乗っ取る攻撃ですね。
記事では、最近のソフトウェアサプライチェーン攻撃でもこの手口が悪用されているとしています。
Nx関連パッケージの侵害、PostHogやTanStack、Emacsの kubernetes-el/kubernetes-el への被害などが例として挙がっていました。
こういう話を聞くたびに思うのですが、サプライチェーン攻撃って「どこか一箇所を固めれば終わり」ではないのが厄介です。
開発者の便利さを支える仕組みほど、攻撃者にも都合がいい。GitHub Actionsはまさにその象徴みたいな存在です。
GitHubやSocketは、pull_request_target は本当に必要なときだけ使うべきだと案内しています。
もし秘密情報や昇格した権限が要らないなら、pull_request に切り替えたほうが安全です。
また、ワークフローに与える権限はできるだけ絞るべきです。
GITHUB_TOKEN に書き込み権限を与えっぱなしにしない。secrets を不用意に渡さない。ユーザー入力がそのままコード実行につながらないようにする。こういう基本が効きます。
そして大事なのは、今回の更新を**“安全装置”ではなく“ガードレール”として見ること**です。
転落を少し防いでくれるけれど、道そのものを完全に安全にはしてくれない。ここを勘違いすると痛い目を見ると思います。
個人的には、これはかなり筋のいい改善だと思います。
理由はシンプルで、よくある事故の型をデフォルトで塞いでいるからです。セキュリティ対策は、派手な新機能より「いつも誰かがやらかすやつを静かに潰す」ほうが効きます。
しかも GitHub Actions は利用者が多いので、こういう小さな変更でも波及効果が大きい。
一方で、既存のワークフローが突然失敗する可能性もあるので、運用側は「何がブロックされたのか」をちゃんと見ないといけません。セキュリティ強化は、たまに現場の摩擦も生みます。そこは避けられないですね。
参考: GitHub Updates actions/checkout to Block Common Pwn Request Attack Patterns