GitHub anunció el 2 de noviembre de 2026 que, a partir del 2 de diciembre, GitHub Actions bloqueará por defecto los eventos pull_request_target en repositorios públicos, salvo que una política de eventos de Actions permita el disparador de forma explícita. La fecha original era el 2 de noviembre y se aplazó un mes. Antes hay dos ventanas de prueba con bloqueo real, de 16:00 a 18:00 UTC: el 9 de noviembre, día de esta publicación, y el 16 de noviembre.
Qué cambia con el bloqueo
pull_request_target se ejecuta en el contexto del repositorio de destino, con acceso a sus secretos, incluso cuando el pull request viene de un fork. Por eso el disparador se usa para tareas que necesitan credenciales en contribuciones externas: etiquetar PRs, comentar resultados, publicar un preview, ejecutar un bot de revisión. Por la misma razón, un workflow que ejecuta código del fork en ese contexto puede filtrar secretos o comprometer el pipeline. GitHub cita ese riesgo como motivo del nuevo comportamiento por defecto.
Durante las ventanas de prueba, las ejecuciones que serían bloqueadas fallan con una anotación de error y no se ejecutan. Fuera de ellas, la regla queda en modo de evaluación: los workflows se ejecutan, con un aviso. El 2 de diciembre el bloqueo pasa a aplicarse siempre.
A quién afecta
Entran los repositorios públicos en los planes GitHub Free, Team y Enterprise Cloud. Quedan fuera los repositorios privados e internos, y también GitHub Enterprise Server. Un repositorio que ya tiene una política de eventos aplicable sigue esa política y no el nuevo comportamiento por defecto.
En la práctica, el mayor impacto recae en quienes mantienen proyectos open source con contribuciones externas y en empresas que publican bibliotecas, SDKs, plugins o temas en repositorios públicos y automatizaron la clasificación de PRs. Si el producto de la empresa vive solo en repositorios privados, este cambio no lo alcanza.
Es la segunda restricción del año sobre el mismo disparador. Desde el 20 de julio, actions/checkout (v7 y las versiones mayores anteriores que siguen soportadas) se niega por defecto a descargar el código del fork en pull_request_target, y solo lo hace con la opción allow-unsafe-pr-checkout. Aquel cambio limitaba lo que el workflow podía descargar; este impide que el workflow empiece.
Qué hacer antes del 2 de diciembre
El primer paso es saber qué workflows dependen del disparador. Una búsqueda de pull_request_target en .github/workflows de los repositorios públicos lo responde, y GitHub remite a Actions Insights para ver qué ejecuciones bloquearía la regla. Un fallo de pull_request_target dentro de las ventanas de prueba viene del bloqueo, no de la infraestructura.
Después, para cada workflow encontrado, hay dos salidas:
- si no necesita secretos ni permiso de escritura, cambiar a
pull_request, que en PRs de fork se ejecuta sin los secretos del repositorio de destino; - si los necesita, crear una política de eventos que permita el disparador, limitada al archivo de ese workflow. GitHub recomienda ese recorte por archivo en lugar de liberar todo el repositorio.
El segundo caso exige revisar el propio workflow: si el workflow permitido ejecuta algo que viene del fork, como un script de build, dependencias instaladas desde el PR o un comando armado con texto del PR, sigue tan expuesto como antes, ahora con permiso explícito. Los workflows de preview entran en este grupo cuando juntan código externo y credenciales de deploy. El mismo razonamiento vale para los recursos que alcanza el preview, como comenté en Un preview seguro debe aislar los recursos conectados.
La decisión corresponde a quien administra la organización o el repositorio en GitHub. Una política creada a nivel de organización se aplica a todos los repositorios públicos a la vez, lo que obliga a acordarla con los mantenedores de cada proyecto.
Qué no está claro todavía
El anuncio no dice si el comportamiento por defecto llegará a repositorios privados e internos, ni si habrá algo equivalente en GitHub Enterprise Server. La fecha de aplicación ya cambió una vez, y parte del material que circula todavía cita el 2 de noviembre. El changelog de GitHub es la referencia para planificar el cambio.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
