GitHub 於 2026 年 11 月 2 日更新 Actions changelog，宣布由 12 月 2 日起，所有公開儲存庫的 pull_request_target 事件將被默認封鎖，除非適用的 Actions event policy 明確允許；私人與內部儲存庫不受影響[1]。這項強制執行原定於 11 月 2 日生效，現已順延一個月，並會在正式生效前安排兩次預演。
風險何在
pull_request_target 在 base repository 的環境中執行，因此可以讀取該儲存庫的 secrets。若 workflow 在這個具備權限的環境中執行來自 fork 的不可信代碼，該代碼便有機會污染整條流水線，或直接竊取 secrets[1]。這個組合長久以來是供應鏈攻擊的常見入口：維護者為了在 PR 上留言或加標籤而使用此觸發器，卻未必意識到 checkout fork 代碼後執行的後果。
GitHub 透過 workflow execution protections 引入這項默認規則，初期以 evaluate 模式運行。在此模式下，規則不會阻止 workflow，只會標示哪些 run 在正式執行時會被攔截，讓管理員先掌握影響範圍[1]。
兩次 brownout 預演
在 12 月 2 日正式生效之前，GitHub 會安排兩個時段臨時執行默認保護。第一次為 11 月 9 日 16:00 至 18:00 UTC，第二次為 11 月 16 日 16:00 至 18:00 UTC，換算香港時間分別是 11 月 10 日及 11 月 17 日凌晨 00:00 至 02:00[1]。
在每個窗口之內，受影響公開儲存庫中被規則攔截的 pull_request_target workflow 會產生失敗的 run，並附上錯誤註解，workflow 本身不會執行。窗口結束後，規則會回復 evaluate 模式，workflow 可以繼續運行，但會出現警告。私人與內部儲存庫在整個過程中都不受影響[1]。
採用 brownout 而非直接切換，是為了讓維護者在可控時段內見到實際失敗，而非在正式生效當日才發現自動化流程中斷。
事前準備
GitHub 建議在 11 月 9 日首次 brownout 之前，先透過 Insights 查看哪些 workflow run 會被規則攔截。之後有兩條路可選：一是保留默認規則，讓 pull_request_target 繼續被封鎖；二是若 workflow 確實依賴此觸發器，在適用的 Actions event policy 中明確允許，並可利用 workflow file targeting 只放行指定 workflow，而非全面開放[1]。
具體設定方式見 GitHub 文件「Control workflow execution」一節。對於仍在使用 pull_request_target 處理外部貢獻的專案，較穩妥的做法是把權限收窄：只在必要時允許特定 workflow，並確保該 workflow 不會在取得 secrets 的情況下執行 fork 的代碼。
適用範圍
新規則適用於 GitHub Free、GitHub Team 及 GitHub Enterprise Cloud 上的公開儲存庫，不適用於 GitHub Enterprise Server[1]。這意味自建伺服器的企業用戶不受此變更影響，但同時亦不會自動獲得這層默認保護，需要自行在內部政策中處理同類風險。
距離正式生效尚有一個月，期間兩次 brownout 提供了實際測試機會。對依賴 pull_request_target 的開源專案而言，現時是檢查 workflow 依賴關係、更新政策與調整權限的時間窗口。
參考資料
[1] pull_request_target blocked by default December 2（2026年11月2日）