pull_request_target en GitHub Actions tiene fecha de bloqueo: el 2 de diciembre de 2026. Ese día GitHub empezará a frenar por defecto ese evento en todos los repositorios públicos, salvo que una política de eventos de Actions lo permita de forma explícita. La fecha original era el 2 de noviembre, este lunes, y la plataforma la movió un mes entero para dar margen a los equipos que mantienen proyectos abiertos.
El cambio llega a los repositorios públicos con los planes GitHub Free, GitHub Team y GitHub Enterprise Cloud. GitHub Enterprise Server queda fuera, y los repositorios privados e internos tampoco entran. Quien tenga un proyecto público con automatización atada a solicitudes de colaboradores externos es el público exacto de este aviso.
La regla forma parte de las protecciones de ejecución de flujos que GitHub presentó este otoño. Ahora mismo corre en modo de evaluación: los flujos se ejecutan, pero la plataforma deja ver cuáles serían bloqueados cuando la protección se aplique en firme. Esa ventana permite auditar con datos reales en vez de buscar a ciegas en cada archivo.
pull_request_target corre en el contexto del repositorio base y puede acceder a sus secretos. Eso lo vuelve práctico para clasificar, etiquetar y publicar comprobaciones con permisos, y a la vez delicado: si un flujo ejecuta código que no merece confianza, llegado desde una bifurcación del proyecto, ese código corre con los secretos del repositorio base en la mano.
Dos ensayos con hora fija antes del cierre
Antes del 2 de diciembre habrá dos cortes de prueba, con hora publicada. El primero cae el lunes 9 de noviembre, de 16:00 a 18:00 en tiempo universal coordinado, y el segundo el lunes 16 de noviembre en el mismo horario. En cada ventana, los intentos de pull_request_target que la regla por defecto bloquee en los repositorios afectados terminarán como ejecuciones fallidas, con una anotación de error visible, y el flujo no llegará a correr.
Terminado cada ensayo, la regla vuelve al modo de evaluación y los flujos corren otra vez con avisos. Un equipo que dependa de ese evento para publicar una vista previa o para correr pruebas con un registro privado descubrirá el 9 de noviembre, en dos horas concretas, qué parte de su automatización se cae cuando la puerta se cierre de verdad.
GitHub pide revisar antes de esa primera fecha la sección Insights, donde se ven las ejecuciones que la regla bloquearía. Con esa lista delante hay dos salidas. Una es dejar la regla por defecto tal como viene y aceptar el bloqueo. La otra es permitir pull_request_target de forma explícita en una política de eventos aplicable, con la opción de apuntar a archivos de flujo concretos para no abrir el evento entero a todo el repositorio.
Un proyecto que ya tenga una política de eventos propia no recibe la regla por defecto encima: la plataforma no la sustituye. El bloqueo alcanza a los repositorios que venían usando la política por defecto de pull_request_target antes de la disponibilidad general de estas protecciones, un matiz que explica por qué dos proyectos parecidos pueden comportarse distinto el 2 de diciembre.
El error que convierte un flujo en una puerta
La documentación de GitHub separa dos eventos que se confunden con facilidad. Con pull_request, el flujo corre desde la combinación de la rama de la solicitud, con un token de solo lectura y sin acceso a otros secretos cuando la solicitud viene de una bifurcación. Con pull_request_target, el flujo y la copia del código salen de la rama por defecto del repositorio base, y por eso reciben un token con permisos de lectura y escritura y acceso a los secretos del repositorio y de la organización.
El peligro aparece cuando quien escribe el flujo cambia esa copia segura por el código de la solicitud. Basta apuntar la acción de descarga al identificador de la cabecera de la solicitud y correr después un comando de construcción o de pruebas: el archivo de construcción que se ejecuta ya es el del colaborador externo. GitHub bautizó ese patrón como solicitud pwn, y lo señala como causa de raíz de varios compromisos de la cadena de suministro, el mismo terreno donde un gusano oculto en paquetes de npm alcanzó 42 repositorios de GitHub en octubre.
La guía de uso seguro añade controles para quien mantenga el evento. Pregunta primero si pull_request resuelve el trabajo sin acceso a secretos; si la respuesta es que sí, ese es el evento correcto. Pide restringir los secretos a los mínimos que el flujo necesita, con permisos del token lo más cortos posible, y recuerda que estos flujos solo leen la caché de la rama por defecto. En ejecutores propios, la exigencia es aislar la máquina y no reutilizarla entre ejecuciones.
Para un mantenedor con pocos recursos, el cálculo es simple y algo incómodo. Etiquetar solicitudes y comentar con permisos se puede mover a otros eventos o a una política explícita bien acotada, con el archivo exacto autorizado. Dejar el evento abierto porque siempre funcionó así es justo el hábito que la regla nueva viene a cortar.
El calendario ya quedó escrito por GitHub: revisión en Insights antes del 9 de noviembre, ensayo ese día de 16:00 a 18:00 UTC, segundo ensayo el 16 en el mismo horario y aplicación permanente el 2 de diciembre de 2026 en los repositorios públicos alcanzados por la regla.
Fuente: GitHub Changelog
