GitHub bloqueará pull_request_target por defecto en repositorios públicos
Un cambio de política en GitHub Actions afecta a los flujos privilegiados de solicitudes de extracción. Así pueden prepararse los responsables.
Más allá de ASPM
AppSec basada en pruebas para equipos que desarrollan con IA
Plexicus usa AI Swarm Pentest para explorar rutas de aplicaciones autorizadas, validar qué es explotable y dar a los equipos evidencia para priorizar la remediación.
Explorar AI Swarm PentestEl 2 de diciembre de 2026, GitHub bloqueará por defecto los eventos pull_request_target en repositorios públicos, salvo que una política de eventos de Actions aplicable los permita expresamente. Antes habrá dos ventanas de aplicación temporal. El cambio protege un límite sensible y puede interrumpir flujos que los equipos esperan ejecutar.
Fechas y alcance
GitHub publicó el calendario actualizado el 2 de noviembre. Antes de la aplicación permanente, la regla está en modo de evaluación: fuera de las ventanas, los flujos afectados pueden ejecutarse con advertencias.
| Fecha | Cambio |
|---|---|
| 9 de noviembre de 2026, 16–18 UTC | Primera ventana de aplicación temporal |
| 16 de noviembre de 2026, 16–18 UTC | Segunda ventana de aplicación temporal |
| 2 de diciembre de 2026 | Comienza el bloqueo por defecto |
Durante las ventanas, una ejecución bloqueada falla con una anotación de error y el flujo no se ejecuta. La regla afecta a repositorios públicos de GitHub Free, Team y Enterprise Cloud. GitHub indica que no afecta a repositorios privados o internos ni a GitHub Enterprise Server.
Por qué importa este evento
pull_request_target se ejecuta en el contexto del repositorio base. Según la guía de uso seguro de GitHub, los flujos privilegiados pueden acceder a permisos de escritura, secretos referenciados y la caché de la rama principal. Descargar y ejecutar contenido no confiable de una solicitud de extracción en ese contexto puede comprometer el pipeline o exponer secretos.
El nombre del evento por sí solo no demuestra una vulnerabilidad. Examina el código, los scripts y los artefactos procesados, los permisos y secretos disponibles y si una contribución desde un fork puede controlar esas entradas. GitHub advierte también que un flujo workflow_run debe tratar con cautela los artefactos de ejecuciones no confiables.
Antes de la primera ventana
- Usa Insights para identificar las ejecuciones que bloquearía la regla y asigna un responsable a cada flujo.
- Decide si el trabajo necesita el evento privilegiado. Para ejecutar código no confiable, considera un flujo
pull_requestcon los permisos mínimos. Prueba los forks y la configuración del repositorio; cambiar el evento no sustituye una revisión de seguridad. - Si el flujo privilegiado es necesario, evita ejecutar código no confiable, limita permisos y revisa los límites de los artefactos. GitHub explica cómo controlar la ejecución de flujos.
- Mantén el bloqueo por defecto cuando sea posible. Si necesitas el evento, GitHub permite políticas explícitas y selección de flujos concretos. Aprueba cada excepción: permitir la ejecución no convierte la entrada en confiable.
- Realiza una prueba controlada antes del 9 de noviembre y define un responsable y un plan de reversión.
Relaciona la decisión con la evidencia
La política determina si un flujo puede comenzar. La revisión debe conservar evidencia de qué ejecutará y a qué credenciales puede acceder: versión del flujo, origen del evento y resultado observado.
AI Swarm Pentest de Plexicus describe la validación con evidencia de aplicaciones y APIs autorizadas; remediation ayuda a convertir hallazgos validados en correcciones revisables. Usa esos flujos junto con una revisión separada de GitHub Actions: un análisis de aplicaciones no demuestra por sí solo que la política del flujo sea segura.
Revisa los repositorios afectados antes de la primera ventana. Descubre Plexicus remediation.
Imagen: captura de un párrafo original de GitHub Docs, Secure use reference, bajo CC BY 4.0. No implica respaldo.
