GitHub Actions заблокирует pull request target по умолчанию со 2 декабря 2026 года

Со 2 декабря 2026 года GitHub Actions блокирует pull_request_target в публичных репозиториях без явного разрешения в политике событий. Окна принудительного применения — 9 и 16 ноября, 16:00–18:00 UTC; до первого окна Insights показывает затронутые workflow.

GitHub Actions заблокирует pull_request_target по умолчанию со 2 декабря 2026 года. Тематическая карточка Comrad404.

Со 2 декабря 2026 года GitHub Actions перестанет запускать workflow по триггеру pull_request_target в публичных репозиториях, если применимая политика событий Actions явно не разрешает этот триггер. Об этом GitHub сообщил 2 ноября 2026 года — в день, на который раньше было назначено принудительное применение. Теперь срок сдвинут на месяц.

Схема: Со 2 декабря 2026 года GitHub Actions перестанет запускать workflow по триггеру pull_request_target в публичных репозиториях; Теперь срок сдвинут на месяц.; 9 ноября 2026 года и 16 ноября 2026 года, оба с 16:00 до 18:00 UTC; После каждого окна правило возвращается в режим evaluate: обычные запуски снова проходят, но с предупреждениями.; Изменение касается публичных репозиториев на GitHub Free, GitHub Team и GitHub Enterprise Cloud.
Основные элементы, разобранные в статье.

Для владельцев публичных репозиториев это значит: workflow, запускаемые этим триггером, после 2 декабря не будут выполняться, пока триггер не разрешат явно. Проверить, какие пайплайны попадут под блокировку, можно до первого окна принудительного применения 9 ноября.

Зачем GitHub меняет поведение по умолчанию

pull_request_target выполняется в контексте базового репозитория и имеет доступ к его секретам. Если такой workflow исполняет недоверенный код из форка — например, скрипт из pull request внешнего контрибьютора, — этот код может скомпрометировать пайплайн или украсть секреты. Блокировка по умолчанию снижает этот риск, а явное разрешение в политике оставляет триггер доступным там, где он нужен.

Правило добавлено через механизмы защиты выполнения workflow (workflow execution protections) и сначала работает в режиме evaluate: до начала принудительного применения видно, какие запуски оно заблокировало бы.

Расписание brownout: 9 и 16 ноября

Временных окон два: 9 ноября 2026 года и 16 ноября 2026 года, оба с 16:00 до 18:00 UTC. В эти часы попытки запуска pull_request_target, которые блокирует правило в затронутых публичных репозиториях, не выполнятся — вместо запуска появится failed run с error annotation. Так видно, какие workflow пострадают после 2 декабря.

После каждого окна правило возвращается в режим evaluate: обычные запуски снова проходят, но с предупреждениями.

Что сделать до первого brownout

До 9 ноября GitHub советует открыть Insights и посмотреть, какие запуски workflow заблокировало бы правило. Дальше два варианта:

  1. Оставить правило по умолчанию — тогда pull_request_target блокируется.
  2. Явно разрешить pull_request_target в применимой политике событий Actions, если workflow от него зависит; через workflow file targeting можно разрешить только конкретные workflow.

Изменение касается публичных репозиториев на GitHub Free, GitHub Team и GitHub Enterprise Cloud. Приватные и внутренние репозитории не затронуты, GitHub Enterprise Server правило тоже не касается.

Чего в анонсе нет

GitHub не приводит оценку того, сколько публичных репозиториев или workflow затронет блокировка, и не сообщает статистику инцидентов с pull_request_target. Все приведённые детали взяты из официального сообщения GitHub; независимых замеров влияния изменения нет.