GitHub усилил защиту цепочек поставки в GitHub Actions: официальный action actions/checkout в версии v7 теперь по умолчанию блокирует распространённые схемы pwn request-атак. The Hacker News пишет, что изменение вступило в силу 18 июня 2026 года, а 16 июля его планируют перенести на все поддерживаемые major-версии action. Речь идёт о сценариях, где workflow с повышенными привилегиями забирает и запускает код из pull request, созданного из форка.
Опасная комбинация обычно строится вокруг триггера pull_request_target. Он выполняется в контексте базового репозитория и может иметь доступ к секретам, write-permissions, кешам и токену GITHUB_TOKEN. Сам по себе такой триггер нужен для доверенной автоматизации — например, меток, комментариев или метаданных pull request. Но если workflow дополнительно делает checkout непроверенного кода из форка и запускает его, атакующий может получить выполнение команд с полномочиями базового проекта.
Новая защита в actions/checkout отказывается забирать head или merge commit fork pull request в pull_request_target и части workflow_run-сценариев, если событие связано с pull request. Авторы workflow могут явно отключить барьер через allow-unsafe-pr-checkout: true, но это уже будет осознанным риском. GitHub подчёркивает, что изменение закрывает наиболее частый путь ошибки, но не превращает небезопасный workflow в безопасный автоматически.
Контекст важен: за последние месяцы атаки на supply chain всё чаще использовали CI/CD как входную точку. The Hacker News упоминает компрометации, связанные с Nx, PostHog, TanStack и пакетом Emacs kubernetes-el. Во всех подобных историях атакующим выгодно не ломать production напрямую, а получить доступ к токенам публикации, секретам сборки или доверенным runner-окружениям, через которые затем можно выпускать вредоносные версии пакетов.
Для разработчиков практический вывод простой: pull_request_target стоит использовать только там, где действительно нужны привилегии базового репозитория. Если workflow не требует секретов и записи, безопаснее перейти на обычный pull_request. Также нужно ограничивать permissions, проверять все места, где пользовательский ввод превращается в команду, и помнить, что новый guardrail покрывает только checkout через официальный action. Если workflow забирает чужой код через git, GitHub CLI или сторонний action, риск pwn request остаётся.
Источник: The Hacker News, 23 июня 2026