GitHub Actions: pull_request_target bloccato di default il 2 dicembre, primi blackout di test questo 9 novembre
A partire dal 2 dicembre 2026, GitHub bloccherà per impostazione predefinita il trigger pull_request_target in tutti i repository pubblici. Prima di allora, due blackout di test di due ore, il 9 e il 16 novembre dalle 17:00 alle 19:00 (ora di Roma/Parigi), faranno fallire i workflow interessati.
Se gestite un repository pubblico su GitHub che utilizza il trigger pull_request_target, segnatevi l’orario: questo lunedì 9 novembre, dalle 17:00 alle 19:00 (ora di Parigi/Roma), i vostri workflow rischiano di fallire. È il primo dei due blackout di prova annunciati da GitHub prima del blocco predefinito di questo trigger, previsto per il 2 dicembre 2026, in tutti i repository pubblici (changelog).
Perché questo trigger è nel mirino
pull_request_target serve soprattutto ad automatizzare le risposte alle pull request provenienti da fork: etichettatura, smistamento, commenti, stati. La sua particolarità: viene eseguito nel contesto del repository di base, con accesso ai suoi segreti e a un token con permessi di scrittura. Finché il workflow esegue solo codice del branch predefinito, non ci sono pericoli. Ma se recupera ed esegue il codice della pull request, un contributore malintenzionato può compromettere la catena di integrazione o sottrarre segreti. È questa la motivazione addotta da GitHub, la cui documentazione avverte: un workflow attivato in questo modo non deve mai compilare né eseguire codice proveniente da una pull request non attendibile con accesso ai segreti.
Il calendario
- Fino al 2 dicembre: la regola predefinita rimane in modalità valutazione, i workflow vengono eseguiti con avvisi.
- 9 e 16 novembre, 16:00-18:00 UTC (17:00-19:00 a Roma/Parigi): blocco temporaneo. I workflow interessati generano esecuzioni fallite con un’annotazione di errore.
- 2 dicembre: blocco permanente per impostazione predefinita, salvo autorizzazione esplicita. La scadenza iniziale era fissata al 2 novembre.
Sono interessati i repository pubblici su GitHub Free, Team ed Enterprise Cloud. I repository privati e interni e GitHub Enterprise Server non lo sono.
Cosa fare prima di lunedì
GitHub consiglia di aprire gli Insights per individuare le esecuzioni che verrebbero bloccate. A questo punto si delineano tre possibilità: se il workflow non necessita di segreti né di permessi di scrittura, passare al trigger pull_request; se ne ha realmente bisogno, autorizzarlo in una policy sugli eventi Actions puntando esclusivamente a quel file di workflow, e verificare che non esegua mai il codice della pull request; altrimenti, lasciare che il blocco faccia il suo corso.
La nostra lettura
pull_request_target è una trappola ben nota tra i manutentori, poiché il confine tra «reagire a una pull request» ed «eseguirne il codice» è facile da superare per errore. Invertire l’impostazione predefinita è la decisione corretta, e i blackout di test evitano sorprese il giorno del rilascio definitivo. La posta in gioco aumenta con gli agenti di programmazione che aprono pull request su larga scala nei progetti pubblici: più aumentano i contributi automatizzati, più un workflow troppo permissivo diventa un bersaglio. Per i manutentori, il lavoro è breve ma va fatto subito: pochi minuti negli Insights evitano una serata di CI tutta in rosso.
Fonti
- GitHub Changelog — pull_request_target blocked by default December 2 (2 novembre 2026) Fonte primaria
- GitHub Docs — Securely using pull_request_target Fonte primaria
Una fonte primaria proviene direttamente dall'azienda, dal laboratorio o dall'ente interessato. Una fonte secondaria riporta l'informazione senza esserne l'autrice: la segnaliamo come tale. Un errore? Consulta la nostra politica di rettifica.
