A partir del 2 de diciembre de 2026, GitHub Actions bloqueará por defecto el evento pull_request_target en todos los repositorios públicos, salvo cuando una política de eventos de Actions permita explícitamente ese disparador. La información es CONFIRMADA: figura en el changelog oficial de GitHub, publicado el 2 de noviembre de 2026.
La aplicación estaba prevista antes para el 2 de noviembre y se pospuso al 2 de diciembre. Hasta entonces, la regla predeterminada funciona en modo de evaluación: los flujos siguen ejecutándose, pero GitHub muestra qué ejecuciones se bloquearían, para que los mantenedores ajusten sus políticas antes del bloqueo definitivo.
Antes de la aplicación permanente, GitHub impondrá temporalmente la regla en dos ventanas de prueba, los llamados brownouts, el 9 y el 16 de noviembre de 2026, de 16:00 a 18:00 UTC. En esas ventanas, los intentos bloqueados se convierten en ejecuciones fallidas con una anotación de error, sin ejecutar el flujo; después de cada ventana, la regla vuelve al modo de evaluación, con advertencias.
El riesgo que motiva el cambio es conocido: pull_request_target se ejecuta en el contexto del repositorio base y puede acceder a sus secretos. Si un flujo ejecuta código no confiable procedente de un fork, ese código podría comprometer el pipeline o robar secretos, la clase de ataque conocida como Pwn Request. Por eso, GitHub recomienda revisar, antes del primer brownout el 9 de noviembre, el informe Insights, que muestra qué ejecuciones se bloquearían.
Qué deben hacer los mantenedores
Hay dos opciones, según GitHub: mantener la regla predeterminada, dejando el disparador bloqueado, o permitir explícitamente pull_request_target en una política de eventos aplicable, preferiblemente dirigiendo solo los archivos de flujo que realmente dependen de él. No se trata de una prohibición absoluta: los repositorios con una política explícita podrán seguir usando el disparador.
La regla no afecta a los repositorios privados e internos, y se aplica a los repositorios públicos en GitHub Free, GitHub Team y GitHub Enterprise Cloud, no a GitHub Enterprise Server. La aplicación automática el 2 de diciembre vale para los repositorios afectados que usaban la política predeterminada de pull_request_target antes de la disponibilidad general de las protecciones de ejecución de flujos.
En la práctica, el mensaje para quienes mantienen automatizaciones de pull requests de forks —como etiquetadores, triaje y verificaciones autenticadas— es simple: auditen ahora, en modo de evaluación, y permitan solo lo necesario. Esperar hasta el 2 de diciembre es arriesgarse a fallos silenciosos en automatizaciones que hoy parecen funcionar.
Crédito de la imagen: GitHub, a través del icono oficial de GitHub.
Fuentes: GitHub Changelog — pull_request_target blocked by default December 2; GitHub Docs — Securely using pull_request_target; GitHub Changelog — Workflow execution protections generally available
Transparencia: este artículo fue producido con ayuda de inteligencia artificial, a partir del cruce de publicaciones públicas en X y de fuentes en internet. Consulte las fuentes originales para confirmar los detalles antes de compartir.
Muse
