GitHub ввёл срок проверки trusted publishing в npm после риска захвата пакетов

GitHub установил 48-часовой срок для непроверенных конфигураций trusted publishing в npm после того, как Bloom Security выявила риск захвата более 1 500 пакетов с совокупным числом загрузок свыше 10 млн. После первой успешной публикации настройка считается проверенной и связывается с неизменяемой идентичностью репозитория.

Изменение касается механизма, который позволяет публиковать npm-пакеты из CI/CD без постоянно хранимых секретов. GitHub также сообщил, что npm впредь не принимает токены trusted publishing, созданные GitHub Actions в событиях issue_comment; ранее такое же ограничение действовало для pull_request_target.

Как работала уязвимость SlugFest

Trusted publishing появился в npm в июле 2025 года. CI/CD-платформа, например GitHub Actions, выпускает для конкретного запуска краткоживущий токен OpenID Connect, а npm сверяет его с заранее разрешённой конфигурацией. Такой подход устраняет необходимость хранить и регулярно менять долгоживущие токены публикации, а также формирует attestations происхождения пакета.

Bloom Security обнаружила, что до первой публикации npm привязывал доверие к читаемому адресу репозитория — slug вида owner/repository — вместо постоянного числового ID. Числовой идентификатор сохраняется при переименовании и передаче репозитория и присутствует в OIDC-токене GitHub, однако до первой успешной публикации npm его не использовал.

Если сопровождающий переименовывал, передавал или удалял репозиторий, прежний slug мог освободиться. Злоумышленник мог создать репозиторий по этому адресу, запустить workflow публикации и представить npm токен с совпадающим slug, но новым ID. В результате сервис выдавал краткосрочные учётные данные для публикации новой версии чужого пакета.

Какие ограничения ввёл GitHub

Теперь новая конфигурация trusted publisher должна выполнить первую успешную публикацию в течение двух суток. Это подтверждает настройку и закрепляет её за неизменяемой идентичностью репозитория. Обычные правки не продлевают срок, а смена репозитория или идентичности проекта требует новой связи доверия и нового 48-часового окна.

По оценке Bloom Security, атака не требует кражи учётных данных, внутреннего доступа или гонки запросов. Достаточно, чтобы привязка ещё не использовалась для публикации, а прежний slug оказался доступен. Новая вредоносная версия при этом выходит под легитимным именем пакета, сохраняя его репутацию, зависимости и историю загрузок.

Что проверить сопровождающим пакетов

GitHub и исследователи советуют провести аудит привязок trusted publisher и убедиться, что указанный slug по-прежнему ведёт к подконтрольному репозиторию. После переименования или передачи репозитория старую привязку следует удалить и создать заново с актуальным адресом.

Организациям также стоит отслеживать неожиданные события публикации npm и удалять привязки доверия при удалении, передаче или переименовании репозиториев. Практический вывод для бизнеса прост: доверенные цепочки CI/CD требуют контроля не только токенов, но и соответствия между именем репозитория и его постоянной идентичностью.