GitHub menjadwalkan brownout pertama untuk event pull_request_target pada 9 November 2026 pukul 16.00–18.00 UTC. Selama jendela dua jam itu, workflow yang terkena kebijakan perlindungan default akan gagal berjalan di repositori publik. Brownout kedua dijadwalkan pada 16 November, sebelum aturan tersebut diberlakukan permanen pada 2 Desember 2026.

Perubahan ini menyasar GitHub Actions, bukan pull request secara umum. Event pull_request_target tetap tersedia, tetapi GitHub akan memblokirnya secara default di repositori publik yang tidak memiliki kebijakan event Actions yang secara eksplisit mengizinkannya. Repositori privat dan internal tidak terkena kebijakan default ini.

Mengapa event ini dianggap berisiko

Perbedaan penting pull_request_target ada pada konteks eksekusinya. Workflow diambil dari branch default repositori dasar, bukan dari branch pull request. Karena berjalan dalam konteks repositori dasar, workflow dapat memperoleh akses yang biasanya tidak diberikan kepada workflow biasa dari fork, termasuk secrets dan token dengan izin tulis—tergantung konfigurasi job.

Model ini berguna untuk beberapa otomatisasi, misalnya memberi label pull request dari fork atau menjalankan pemeriksaan tertentu dengan konteks repositori utama. Masalahnya muncul ketika workflow kemudian mengambil atau menjalankan kode yang dikirim dari pull request. Kode itu belum dipercaya. Jika workflow memiliki akses secrets, kesalahan konfigurasi dapat membuka jalan bagi kode dari fork untuk membaca kredensial atau memodifikasi repositori.

GitHub menyebut risiko ini sebagai alasan utama di balik perlindungan baru. Event tersebut berjalan dari sisi repositori dasar dan dapat mengakses secrets. Jika kode yang tidak tepercaya dari fork ikut dieksekusi, pipeline bisa dikompromikan dan secrets dapat dicuri.

Apa yang terjadi pada 9 November

Menurut GitHub, aturan default saat ini berjalan dalam mode evaluasi. Dalam mode tersebut, workflow masih dapat berjalan, sementara pemilik repositori bisa melihat workflow mana yang akan diblokir setelah penegakan dimulai. Brownout mengubah perilaku itu untuk sementara: workflow yang terkena aturan akan menghasilkan run gagal dengan anotasi error dan tidak dieksekusi.

Setelah jendela brownout berakhir, aturan kembali ke mode evaluasi sampai penegakan permanen dimulai. Dengan begitu, maintainer memiliki dua kesempatan untuk menemukan workflow yang bergantung pada pull_request_target tanpa harus menunggu kegagalan permanen pada Desember.

GitHub menyarankan maintainer membuka policy insights untuk memeriksa dampaknya. Pencarian juga perlu mencakup workflow yang tidak terlihat dari nama file—yang penting adalah trigger di dalam konfigurasi YAML, terutama penggunaan pull_request_target dan langkah yang memproses kode dari pull request.

Dua pilihan untuk maintainer

Jika workflow tidak benar-benar membutuhkan pull_request_target, pilihan yang lebih aman adalah menggantinya dengan event lain yang sesuai, seperti pull_request. Event biasa berjalan dengan batasan yang lebih ketat untuk pull request dari fork, sehingga tidak cocok untuk setiap kebutuhan, tetapi dapat mengurangi permukaan risiko ketika workflow hanya perlu melakukan pemeriksaan tanpa secrets atau hak tulis.

Jika workflow memang membutuhkan pull_request_target, maintainer dapat membuat atau memperbarui kebijakan event Actions yang secara eksplisit mengizinkannya. GitHub juga menyebut bahwa izin dapat ditargetkan ke workflow tertentu, bukan harus membuka event tersebut untuk semua workflow. Pilihan ini sebaiknya diambil setelah isi workflow diperiksa dan kebutuhan aksesnya jelas.

Ada satu peringatan tambahan. Dokumentasi GitHub menjelaskan bahwa workflow pull_request_target menggunakan kode dari branch default repositori dasar. Namun, tindakan checkout yang tidak menentukan ref juga memiliki perilaku khusus. Mengizinkan checkout kode dari fork secara eksplisit dapat mengembalikan risiko yang justru ingin dikurangi oleh event ini. Opsi seperti allow-unsafe-pr-checkout: true hanya layak dipakai setelah maintainer memastikan kode yang di-checkout tidak pernah dieksekusi.

Checklist sebelum brownout

Maintainer repositori publik sebaiknya memeriksa policy insights, mencari semua trigger pull_request_target, dan mencatat secrets atau permission yang tersedia pada setiap job. Lalu, pisahkan workflow yang hanya membutuhkan metadata pull request dari workflow yang benar-benar memerlukan akses repositori utama.

Untuk workflow yang berisiko rendah, pindah ke pull_request mungkin cukup. Untuk workflow yang harus tetap menggunakan event lama, batasi izin token, hindari menjalankan kode dari fork, dan izinkan hanya workflow yang memang diperlukan melalui kebijakan Actions. Pull request yang gagal saat brownout bukan sekadar gangguan jadwal; ia merupakan sinyal bahwa pipeline perlu disesuaikan sebelum 2 Desember.

Sumber https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/ Sumber konteks: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target Dokumentasi kebijakan: https://docs.github.com/actions/how-tos/administer/control-workflow-execution