GitHub изменил правила доверенной публикации в npm после того, как исследователи обнаружили способ перехватывать пакеты через заброшенные настройки. Новая конфигурация доверенного издателя, которую ещё не проверила успешная публикация, действует 48 часов. Если за это время пакет не опубликован, настройка истекает. После первой успешной публикации конфигурация считается проверенной и срока действия больше не имеет. Изменение репозитория или проекта требует создать связь заново и пройти новый 48-часовой период; обычное редактирование настроек отсчёт не перезапускает.
По словам GitHub, мера призвана не дать злоумышленнику воспользоваться прежним именем репозитория после смены его владельца. В обновлённой документации сказано, что первая успешная публикация проверяет конфигурацию и привязывает её к неизменяемому идентификатору репозитория. Кроме того, npm теперь отклоняет токены доверенной публикации из GitHub Actions, запущенных событием issue_comment. Ранее такое ограничение уже действовало для события pull_request_target.
Лазейку выявила компания Bloom Security. О находке она сообщила GitHub 6 июня 2026 года. Исследователи насчитали более 1 500 уязвимых пакетов, скачанных в общей сложности свыше 10 миллионов раз. Потенциальную цепочку перехвата они назвали SlugFest: скомпрометированный пакет мог стать началом масштабной атаки на цепочку поставок, подобной Shai-Hulud.
Доверенную публикацию npm запустил в июле 2025 года, чтобы разработчики могли выпускать пакеты из систем CI/CD, например GitHub Actions, без постоянных секретов. Разработчик настраивает доверенного издателя, платформа CI/CD выдаёт короткоживущий криптографический токен для конкретного запуска workflow, а реестр npm проверяет токен по заранее заданной конфигурации. Такой подход избавляет от необходимости хранить и вручную обновлять долгосрочные npm-токены. При публикации также автоматически создаются аттестации происхождения: по ним можно выяснить, где собрали пакет и кто его опубликовал.
Проблема была в том, что npm сначала сверял репозиторий с его текстовым именем, или slug, в формате owner/repository, а не с постоянным идентификатором GitHub. Числовые ID репозиториев сохраняются при переименовании и передаче другому владельцу и содержатся в OIDC-токенах. Но, как объяснил исследователь Голан Майерс, npm игнорировал эти ID, пока репозиторий не опубликовал версию пакета. Неиспользованная настройка поэтому могла оставаться привязанной лишь к имени, которое впоследствии освобождалось после переименования, передачи или удаления репозитория.
Для атаки требовалось, чтобы настройка доверенного издателя жертвы ссылалась на slug, который злоумышленник мог занять, а репозиторий никогда прежде не использовался для публикации версии этого пакета в npm. Злоумышленник регистрировал освободившееся имя и запускал workflow публикации. GitHub Actions создавал OIDC-токен с этим slug и новым числовым ID репозитория. Когда токен поступал в npm, реестр находил совпадение по сохранённому имени и выдавал учётные данные для публикации. Получив временный токен для чужого пакета, атакующий мог загрузить вредоносное обновление.
Такая версия выходила бы под настоящим именем пакета и наследовала его репутацию, число скачиваний и связи с зависимыми проектами. Майерс подчёркивал: для атаки не нужны инсайдерские знания, кража учётных данных или гонка процессов. Достаточно свободного slug и неиспользованной настройки, что он назвал вопросом гигиены репозитория. По его сравнению, прежняя система напоминала замок, который проверяет адрес дома, а не его владельца: прежний хозяин уезжает, новый получает ключ.
Отдельный риск, по предупреждению Bloom Security, связан с ИИ-агентами на компьютерах разработчиков. Они могут самостоятельно разрешать зависимости, выбирать последнюю версию пакета и редко проверять его происхождение. Майерс описал возможную цепочку: агент сопровождающего проекта скачивает скомпрометированный пакет, после чего атакующий использует эту конечную точку, чтобы внедрить вредоносный код в популярный пакет. Тогда обновление может дойти до всех его пользователей без проверки человеком.
Разработчикам, чьи репозитории переименовывали или передавали, советуют удалить прежнюю связь доверия и создать новую с актуальным slug. То же следует делать при удалении, передаче или переименовании репозитория; кроме того, стоит отслеживать неожиданные публикации в npm. Bloom Security также сообщала о другой проблеме под названием Extension Resurrection. В публикации она датирована словами «ранее в августе», без указания года: исследователи обнаружили, что Open VSX и Microsoft VS Code Marketplace допускали ссылки в наборах расширений на расширения, которых ещё не было в каталогах. Заняв свободное пространство имён, атакующий мог опубликовать там вредоносный код, который устанавливался бы вместе с доверенным набором даже у тех, кто уже устанавливал его раньше. Bloom Security выявила 87 таких наборов в Open VSX и 677 в VS Code Marketplace. Поскольку расширения имеют полный доступ к хост-системе, Майерс предупредил, что подобная подмена может привести к удалённому выполнению кода под видом легитимного дополнения.
Изображение носит иллюстративный характер
По словам GitHub, мера призвана не дать злоумышленнику воспользоваться прежним именем репозитория после смены его владельца. В обновлённой документации сказано, что первая успешная публикация проверяет конфигурацию и привязывает её к неизменяемому идентификатору репозитория. Кроме того, npm теперь отклоняет токены доверенной публикации из GitHub Actions, запущенных событием issue_comment. Ранее такое ограничение уже действовало для события pull_request_target.
Лазейку выявила компания Bloom Security. О находке она сообщила GitHub 6 июня 2026 года. Исследователи насчитали более 1 500 уязвимых пакетов, скачанных в общей сложности свыше 10 миллионов раз. Потенциальную цепочку перехвата они назвали SlugFest: скомпрометированный пакет мог стать началом масштабной атаки на цепочку поставок, подобной Shai-Hulud.
Доверенную публикацию npm запустил в июле 2025 года, чтобы разработчики могли выпускать пакеты из систем CI/CD, например GitHub Actions, без постоянных секретов. Разработчик настраивает доверенного издателя, платформа CI/CD выдаёт короткоживущий криптографический токен для конкретного запуска workflow, а реестр npm проверяет токен по заранее заданной конфигурации. Такой подход избавляет от необходимости хранить и вручную обновлять долгосрочные npm-токены. При публикации также автоматически создаются аттестации происхождения: по ним можно выяснить, где собрали пакет и кто его опубликовал.
Проблема была в том, что npm сначала сверял репозиторий с его текстовым именем, или slug, в формате owner/repository, а не с постоянным идентификатором GitHub. Числовые ID репозиториев сохраняются при переименовании и передаче другому владельцу и содержатся в OIDC-токенах. Но, как объяснил исследователь Голан Майерс, npm игнорировал эти ID, пока репозиторий не опубликовал версию пакета. Неиспользованная настройка поэтому могла оставаться привязанной лишь к имени, которое впоследствии освобождалось после переименования, передачи или удаления репозитория.
Для атаки требовалось, чтобы настройка доверенного издателя жертвы ссылалась на slug, который злоумышленник мог занять, а репозиторий никогда прежде не использовался для публикации версии этого пакета в npm. Злоумышленник регистрировал освободившееся имя и запускал workflow публикации. GitHub Actions создавал OIDC-токен с этим slug и новым числовым ID репозитория. Когда токен поступал в npm, реестр находил совпадение по сохранённому имени и выдавал учётные данные для публикации. Получив временный токен для чужого пакета, атакующий мог загрузить вредоносное обновление.
Такая версия выходила бы под настоящим именем пакета и наследовала его репутацию, число скачиваний и связи с зависимыми проектами. Майерс подчёркивал: для атаки не нужны инсайдерские знания, кража учётных данных или гонка процессов. Достаточно свободного slug и неиспользованной настройки, что он назвал вопросом гигиены репозитория. По его сравнению, прежняя система напоминала замок, который проверяет адрес дома, а не его владельца: прежний хозяин уезжает, новый получает ключ.
Отдельный риск, по предупреждению Bloom Security, связан с ИИ-агентами на компьютерах разработчиков. Они могут самостоятельно разрешать зависимости, выбирать последнюю версию пакета и редко проверять его происхождение. Майерс описал возможную цепочку: агент сопровождающего проекта скачивает скомпрометированный пакет, после чего атакующий использует эту конечную точку, чтобы внедрить вредоносный код в популярный пакет. Тогда обновление может дойти до всех его пользователей без проверки человеком.
Разработчикам, чьи репозитории переименовывали или передавали, советуют удалить прежнюю связь доверия и создать новую с актуальным slug. То же следует делать при удалении, передаче или переименовании репозитория; кроме того, стоит отслеживать неожиданные публикации в npm. Bloom Security также сообщала о другой проблеме под названием Extension Resurrection. В публикации она датирована словами «ранее в августе», без указания года: исследователи обнаружили, что Open VSX и Microsoft VS Code Marketplace допускали ссылки в наборах расширений на расширения, которых ещё не было в каталогах. Заняв свободное пространство имён, атакующий мог опубликовать там вредоносный код, который устанавливался бы вместе с доверенным набором даже у тех, кто уже устанавливал его раньше. Bloom Security выявила 87 таких наборов в Open VSX и 677 в VS Code Marketplace. Поскольку расширения имеют полный доступ к хост-системе, Майерс предупредил, что подобная подмена может привести к удалённому выполнению кода под видом легитимного дополнения.
