GitHub Actions bloqueará pull_request_target por defecto: el plazo se aplaza al 2 de diciembre

El 2 de noviembre de 2026, GitHub anunció que aplaza al 2 de diciembre el bloqueo por
defecto de los workflows disparados por pull_request_target en repositorios
públicos. El plazo, fijado un mes antes, da más tiempo a los equipos para auditar sus
pipelines antes de que la plataforma corte por defecto un disparador asociado con frecuencia
a fugas de secretos. El cambio afecta a los planes GitHub Free, Team y Enterprise Cloud, y
forma parte de una serie de
cambios de gobernanza que GitHub ha desplegado este otoño.

#Qué cambia el 2 de diciembre

A partir del 2 de diciembre de 2026, GitHub Actions bloqueará por defecto los eventos
pull_request_target en todos los repositorios públicos, salvo que una política
de eventos de Actions los permita explícitamente. Los repositorios privados e internos no se
ven afectados por este cambio, ni tampoco las instancias de GitHub Enterprise Server.

#Por qué este disparador preocupa a GitHub

A diferencia de pull_request, el disparador pull_request_target
ejecuta el workflow en el contexto del repositorio base y no en el de la fork de origen.

Este disparador se ejecuta en el contexto del repositorio base y puede acceder a sus secretos.

Un workflow mal construido, que extrae y ejecuta código de una fork sin precaución, expone
entonces los tokens y secretos del repositorio principal a código no confiable. Es este
patrón, documentado desde hace años en informes de seguridad de CI/CD, el que GitHub busca
cerrar con este bloqueo por defecto.

#A quién afecta, y a quién no

#Calendario de la transición

Durante las dos ventanas de «brownout», las ejecuciones afectadas fallan con una anotación
de error explícita, lo que permite identificar con precisión los workflows que hay que
corregir antes del plazo final.

#Cómo reaccionar antes del plazo

Los equipos que dependen legítimamente de pull_request_target, por ejemplo
para publicar un comentario en una pull request de una fork sin ejecutar nunca su código,
pueden permitirlo explícitamente mediante una política de eventos de Actions que apunte a los
archivos de workflow concernidos, en la misma línea que
el ajuste reciente del acceso a la caché de CI:

name: comment-on-fork-pr
on:
  pull_request_target:
    types: [opened, synchronize]

permissions:
  pull-requests: write

jobs:
  comment:
    runs-on: ubuntu-latest
    steps:
      # Sin checkout del código de la fork: solo se usa la API.
      - name: Publicar un comentario
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: "Gracias por esta contribución."
            })

#Lo que hay que recordar

El bloqueo por defecto de pull_request_target en repositorios públicos se
aplaza un mes, hasta el 2 de diciembre de 2026. Los mantenedores de proyectos open source
tienen hasta el 9 de noviembre para auditar sus workflows con Insights, y después hasta el 16
de noviembre para observar las dos ventanas de prueba antes del cambio definitivo. Una
política de eventos de Actions permite conservar los usos legítimos del disparador sin
reintroducir el riesgo de fuga de secretos.

Para profundizar: el anuncio completo en el
changelog de GitHub.