GitHub с 2 декабря ограничит pull_request_target в публичных репозиториях

GitHub с 2 декабря 2026 года по умолчанию будет блокировать запуск GitHub Actions по событию pull_request_target в публичных репозиториях. Как пишет Хабр, командам, которым нужны такие сценарии, придётся отдельно разрешить событие в политиках Actions. Изначально ограничение собирались ввести 2 ноября, но срок перенесли на месяц.

Почему под ограничение попало это событие

pull_request_target используют для автоматизации работы с запросами на включение изменений, в том числе поступающими из форков. Сценарий может, например, назначить метку или добавить комментарий. Новое правило касается не этих действий как таковых, а условий, в которых выполняется сценарий.

Он работает в контексте основного репозитория и может получить доступ к его секретам. Если при этом сценарий запускает непроверенный код из стороннего форка, злоумышленник потенциально может похитить секреты или вмешаться в работу CI/CD. GitHub ограничивает запуск по умолчанию, но оставляет возможность сохранить событие для сценариев, которым оно действительно необходимо.

Само разрешение не устраняет риск: значение имеет и то, какие действия выполняет сценарий после запуска.

Сроки перехода и кого затронет правило

Сейчас политика работает в режиме оценки — evaluate: сценарии продолжают запускаться. Администраторы уже могут открыть Policy insights в настройках GitHub Actions и увидеть, какие из них перестанут выполняться при включении блокировки. Так последствия изменения можно проверить заранее, не дожидаясь постоянного ограничения.

До 2 декабря GitHub дважды временно включит блокировку: 9 и 16 ноября 2026 года, каждый раз с 16:00 до 18:00 UTC (19:00–21:00 мск). В эти часы сценарий, подпадающий под новое правило, не запустится. Вместо выполнения GitHub создаст запись о неудачном запуске с сообщением об ошибке. После каждого такого периода политика вновь перейдёт в режим оценки.

Со 2 декабря блокировка станет постоянной по умолчанию. Изменение касается публичных репозиториев на GitHub Free, GitHub Team и GitHub Enterprise Cloud. Приватные и внутренние репозитории оно не затронет; на GitHub Enterprise Server новое правило также не распространяется. Поэтому начинать проверку стоит с публичных репозиториев, где сценарии используют именно pull_request_target.

Что проверить команде сайта

Если разработка сайта идёт в публичном репозитории, до 9 ноября стоит посмотреть Policy insights в настройках GitHub Actions. Сейчас успешный запуск сценария ещё не означает, что он продолжит работать после 2 декабря: режим оценки показывает будущие ограничения, но пока не останавливает выполнение.

После проверки можно разобрать каждый затронутый сценарий по его задаче:

• Если pull_request_target не требуется, перейти на pull_request там, где это возможно.
• Если без события задача не решается, оставить его в политике только для тех файлов сценариев, которым оно действительно нужно.
• Если сценарий запускать не следует, сохранить блокировку по умолчанию.

Для разработчиков проверка не заканчивается настройкой политики. GitHub рекомендует не выполнять непроверенный код из сторонних запросов на изменения, когда ему доступны секреты репозитория или привилегированный GITHUB_TOKEN. Разрешение события возвращает возможность запуска, но не делает такую комбинацию безопасной. Вопрос защиты секретов важен и за пределами этого изменения: в блоге уже рассказывали о действующих секретах, обнаруженных в публичных репозиториях GitHub.

Владельцам сайтов и маркетологам необязательно разбираться в синтаксисе сценариев. Достаточно спросить команду, есть ли в публичном репозитории запуски по pull_request_target и проверено ли, что произойдёт с ними 9 и 16 ноября, а затем — со 2 декабря. Если такая автоматизация участвует в работе с запросами на изменения, лучше узнать о необходимости правок до неудачного запуска.

Моё мнение: сначала упростить, потом разрешать

Я бы не включал исключение только ради сохранения прежнего поведения. Сначала стоит выяснить, зачем сценарию именно pull_request_target и можно ли обойтись pull_request. По моему опыту, решение с меньшим доступом проще проверить и поддерживать, чем исключение, о причине которого команда со временем может забыть.

Если событие всё-таки необходимо, я бы ограничил разрешение нужными сценариями и отдельно пересмотрел, что они делают с кодом из сторонних форков. Здесь полезно проговорить решение внутри команды: политика определяет, может ли сценарий запуститься, а его безопасность зависит ещё и от того, что он выполняет и к чему получает доступ.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. GitHub с 2 декабря начнёт блокировать pull_request_target в публичных репозиториях habr.com

Об авторе

Руй Силва

опытный full-stack-разработчик

Разрабатываю веб-сервисы и помогаю командам не усложнять архитектуру раньше времени. Часто разбираю с младшими коллегами, почему простое решение иногда надёжнее модного.

Все публикации автора