GitHub sẽ chặn pull_request_target mặc định: đội CI/CD cần rà gì trước 2/12?

Bài viết này do AI tạo ra, tổng hợp từ GitHub Changelog ngày 2/11/2026 và tài liệu GitHub Actions.

GitHub thông báo từ ngày 2/12/2026, GitHub Actions sẽ chặn mặc định sự kiện pull_request_target trong mọi repository public, trừ khi policy sự kiện Actions áp dụng đã cho phép rõ. Đây là thay đổi bảo mật có thể làm CI thất bại, nhưng mục tiêu là giảm nguy cơ workflow chạy mã từ fork trong ngữ cảnh có secrets của repository gốc.

Tóm tắt nhanh

Phạm vi: repository public trên GitHub Free, Team và Enterprise Cloud.
Không áp dụng cho repository private, internal và GitHub Enterprise Server.
Ngày enforcement cố định: 2/12/2026.
Brownout kiểm thử: 9/11 và 16/11/2026, 16:00–18:00 UTC.
Policy hiện chạy evaluate mode để đội ngũ thấy workflow nào có thể bị chặn.

Vì sao `pull_request_target` nhạy cảm?

pull_request_target chạy trong ngữ cảnh repository base. Vì vậy workflow có thể truy cập secrets và quyền của repository gốc. Nếu workflow checkout hoặc thực thi mã không tin cậy từ fork, pull request độc hại có thể biến CI thành đường đánh cắp secrets hoặc sửa đổi tài nguyên. GitHub chọn chặn mặc định trên repo public vì đây là nơi fork thường xuyên xuất hiện.

Lịch brownout trước khi chặn vĩnh viễn

Trong hai khung 16:00–18:00 UTC ngày 9/11 và 16/11, GitHub sẽ áp dụng bảo vệ mặc định. Những workflow bị chặn tạo failed run kèm error annotation và không được thực thi. Kết thúc mỗi brownout, policy quay lại evaluate mode, workflow có thể tiếp tục chạy nhưng có cảnh báo. Đây là cơ hội kiểm chứng dependency trước deadline 2/12.

Việc đội DevSecOps cần làm

Dùng Insights để nhận diện workflow pull_request_target bị policy đánh dấu.
Rà các bước checkout, script shell, action bên thứ ba và input có thể lấy từ pull request.
Nếu không thật sự cần trigger này, chuyển luồng kiểm tra mã fork sang pull_request với quyền tối thiểu.
Nếu bắt buộc dùng, tạo Actions event policy cho phép có chủ đích; ưu tiên workflow file targeting thay vì mở rộng toàn cục.
Chạy thử trong cả hai brownout và giữ bằng chứng failed run để sửa trước enforcement.

Caveat vận hành

Cho phép lại pull_request_target không tự làm workflow an toàn. Rủi ro vẫn nằm ở việc checkout ref của fork rồi chạy code, cài dependency hoặc truyền dữ liệu pull request vào lệnh có secrets. Policy là hàng rào giảm tai nạn; thiết kế workflow theo quyền tối thiểu vẫn là lớp bảo vệ chính.

Phân tích

Thay đổi này tác động trực tiếp tới CI public có bot, labeler, preview deployment và automation kiểm tra pull request. Điểm quan trọng là GitHub không chặn ngay không báo trước: evaluate mode và hai brownout biến sự kiện thành bài kiểm tra vận hành. Đội chỉ xem CI là công cụ build sẽ thấy các job đỏ bất ngờ; đội coi CI là bề mặt tấn công sẽ dùng brownout để phân loại workflow, giảm quyền token và ghi rõ ngoại lệ. Deadline 2/12 là mốc cần đưa vào backlog bảo mật, không phải việc để tới ngày đó mới xử lý.