GitHub заблокирует pull_request_target с 2 декабря 2026

С 2 декабря 2026 года GitHub Actions по умолчанию будет блокировать события pull_request_target во всех публичных репозиториях, если разрешение не выдано явной политикой. До этого пройдут два тестовых окна, 9 и 16 ноября с 16:00 до 18:00 UTC (19:00–21:00 по Москве): в это время заблокированные запуски будут падать с ошибкой. Если у вашего подрядчика или у вас публичный репозиторий с автоматической разметкой пулл-реквестов, проверкой сборки или комментариями ботов, откройте его workflow-файлы до окна.

Что именно меняется

Триггер pull_request_target запускает workflow в контексте основного репозитория, с доступом к его секретам. Если такой workflow забирает и выполняет код из форка, чужой пулл-реквест может украсть токены или испортить релиз. Поэтому GitHub раньше уже ограничил небезопасный checkout в actions/checkout, а теперь закрывает сам триггер.

Блокировка действует и для безопасных сценариев: если workflow не разрешён политикой события Actions, он не запустится. Сейчас правило работает в режиме оценки: запуски идут, а в Insights видно, какие из них были бы заблокированы. Раньше называлась дата 2 ноября, по данным GitHub и Socket её перенесли на 2 декабря.

Кого это касается

Что сделать до 9 ноября

1. Найдите поиском по репозиторию все файлы в .github/workflows со строкой pull_request_target.
2. Откройте Insights и посмотрите запуски, которые правило пометило бы как блокируемые.
3. Для каждого workflow решите: переехать на другой триггер или оставить pull_request_target и разрешить его политикой события Actions. Политика может указывать на конкретные файлы, включать весь репозиторий не обязательно.
4. Автоматизацию с низким риском (метки, комментарии, назначение ревьюеров) перенесите на безопасный вариант, где код из форка не выполняется.
5. Проверьте результат в окно 9 или 16 ноября: упавший запуск с аннотацией покажет, что сломается 2 декабря.

Что это значит для владельца сайта

Если сайт или приложение вам разрабатывали в публичном репозитории, спросите подрядчика, есть ли там pull_request_target, и кто держит секреты деплоя. На практике многие проекты хранят ключи сервера и токены в секретах репозитория, поэтому ошибка в одном workflow бьёт по всему проекту. Нужен независимый взгляд на сборку и доступы: для этого есть аудит безопасности, а текущие правки и обновления зависимостей берёт на себя поддержка сайта. Про свежий пример цепочки поставки читайте в материале Node.js 26 станет LTS: план перехода.