GitHub Actions: pull_request_target bloqueado por defecto el 2 de diciembre, primeros cortes de prueba este 9 de noviembre
A partir del 2 de diciembre de 2026, GitHub bloqueará por defecto el activador pull_request_target en todos los repositorios públicos. Antes de eso, dos cortes de prueba de dos horas, los días 9 y 16 de noviembre de 17:00 a 19:00 (hora peninsular española), harán fallar los flujos de trabajo afectados.
Si mantienes un repositorio público en GitHub que utiliza el activador pull_request_target, anota el horario: este lunes 9 de noviembre, de 17:00 a 19:00 (hora peninsular española), tus flujos de trabajo podrían fallar. Es el primero de los dos cortes de prueba anunciados por GitHub antes del bloqueo por defecto de este activador, el 2 de diciembre de 2026, en todos los repositorios públicos (changelog).
Por qué está en el punto de mira este activador
pull_request_target sirve sobre todo para automatizar reacciones a solicitudes de extracción (pull requests) provenientes de bifurcaciones (forks): etiquetado, clasificación, comentarios, estados. Su particularidad: se ejecuta en el contexto del repositorio base, con acceso a sus secretos y a un token con permisos de escritura. Mientras el flujo de trabajo solo ejecute código de la rama por defecto, no supone ningún riesgo. Sin embargo, si obtiene y ejecuta el código de la pull request, un colaborador malintencionado puede comprometer la cadena de integración o sustraer secretos. Es el motivo expuesto por GitHub, cuya documentación advierte: un flujo de trabajo activado de esta forma nunca debe compilar ni ejecutar el código de una pull request no fiable con acceso a los secretos.
El calendario
- Hasta el 2 de diciembre: la regla por defecto funciona en modo de evaluación, los flujos de trabajo se ejecutan con avisos.
- 9 y 16 de noviembre, de 16:00 a 18:00 UTC (17:00-19:00 en Madrid): bloqueo temporal. Los flujos de trabajo afectados crean ejecuciones fallidas con una anotación de error.
- 2 de diciembre: bloqueo permanente por defecto, salvo autorización explícita. El plazo inicial era el 2 de noviembre.
Están afectados los repositorios públicos de GitHub Free, Team y Enterprise Cloud. Los repositorios privados e internos y GitHub Enterprise Server no lo están.
Qué hacer antes del lunes
GitHub aconseja entrar en Insights para detectar las ejecuciones que resultarían bloqueadas. A partir de ahí, tres opciones: si el flujo de trabajo no necesita secretos ni permisos de escritura, cambiar al activador pull_request; si realmente los requiere, autorizarlo en una política de eventos de Actions apuntando únicamente a ese archivo de flujo de trabajo y verificar que nunca ejecute el código de la pull request; en caso contrario, dejar que el bloqueo cumpla su función.
Nuestro análisis
pull_request_target es una trampa bien conocida entre los desarrolladores que mantienen proyectos, ya que el límite entre «reaccionar a una pull request» y «ejecutar su código» es fácil de traspasar por descuido. Modificar el ajuste por defecto es la decisión acertada, y los cortes de prueba evitan sorpresas el día señalado. El problema adquiere mayor peso con los agentes de código que abren pull requests de forma masiva en proyectos públicos: cuantas más contribuciones automatizadas existen, más se convierte un flujo de trabajo demasiado permisivo en un objetivo atractivo. Para quienes mantienen repositorios, la tarea es breve pero inaplazable: unos minutos en Insights evitan una tarde con la CI teñida de rojo.
Fuentes
- GitHub Changelog — pull_request_target blocked by default December 2 (2 de noviembre de 2026) Fuente primaria
- GitHub Docs — Securely using pull_request_target Fuente primaria
Una fuente primaria procede directamente de la empresa, el laboratorio o la organización implicados. Una fuente secundaria recoge la información sin ser su autora: la señalamos como tal. ¿Has visto un error? Consulta nuestra política de correcciones.
