GitHub предпринял шаги по аннулированию непроверенных конфигураций доверенной публикации npm через 48 часов после их создания. Это произошло после того, как исследователи обнаружили, что злоумышленник может публиковать новые версии пакета другого пользователя, не крадя его учетные данные. «Ваша конфигурация становится проверенной и освобождается от аннулирования после первой успешной публикации», — заявила дочерняя компания Microsoft. «Изменение репозитория или идентификатора проекта требует новых доверительных отношений со свежим 48-часовым окном проверки — обычные правки не перезапускают срок».
Изменение устраняет риск, связанный с доверием к имени репозитория или проекта, которое меняет владельца, заявили в GitHub, добавив, что npm также будет отклонять токены доверенной публикации из событий issue_comment GitHub Actions в будущем, наряду с существующим ограничением pull_request_target.
В обновлении своей документации GitHub заявляет, что недавно созданная конфигурация доверенного издателя должна завершить свою первую успешную публикацию в течение двух дней, что проверит конфигурацию и привяжет ее к «неизменяемому идентификатору репозитория».
Это изменение стало ответом на выводы компании Bloom Security, которая обнаружила лазейку в доверенной публикации npm, позволяющую захватить тысячи пакетов и запустить каскадную атаку на цепочку поставок в стиле «Дюны». Об этих находках было сообщено GitHub 6 июня 2026 года.
«Представьте себе: злоумышленник компрометирует один пакет. ИИ-агент на устройстве популярного сопровождающего пакета автономно загружает его для проекта», — сказал исследователь безопасности Голан Майерс. «Эта единственная точка входа используется для внедрения вредоносного кода в популярный пакет. Все пользователи пакета подвергаются риску. И все это потому, что один человек с правильным доступом был скомпрометирован».
Доверенная публикация была представлена в npm в июле 2025 года как метод аутентификации без учетных данных, который позволяет разработчикам публиковать пакеты npm из платформы CI/CD, такой как GitHub Actions, с использованием токенов OpenID Connect (OIDC).
При настройке доверенной публикации поставщик CI/CD разработчика генерирует краткосрочный криптографический токен для конкретного запуска рабочего процесса, который реестр npm проверяет по предварительно авторизованной конфигурации.
Это устраняет необходимость хранения, ротации или ручного управления долгосрочными секретами npm, снижая риск утечки учетных данных. Он также автоматически генерирует подтверждения происхождения для пакетов npm, позволяя пользователям установить, где был создан пакет и кто его опубликовал, тем самым укрепляя безопасность цепочки поставок программного обеспечения.
Однако, как обнаружила Bloom Security, эта архитектура безопасности страдала от проблемы с идентификацией репозитория, также называемого «slug» (т. е. комбинация владельца или организации и имени репозитория, отформатированная как «owner/repository»).
«Он записывает адрес репозитория […] вместо постоянного идентификатора, присвоенного GitHub, по крайней мере, до тех пор, пока из этого репозитория не будет опубликована версия», — пояснил Майерс. «Это похоже на замок, который проверяет адрес на двери, а не на владельца дома: когда владелец уезжает, тот, кто въезжает, получает ключ».
Другими словами, числовые идентификаторы, которые сохраняются при переименовании и передаче репозиториев, передаются токенами OIDC GitHub, но полностью игнорируются npm до первой успешной публикации из этого репозитория.
Это означает, что доверие привязано к имени, а не к неизменяемому идентификатору репозитория — лазейке, которой можно злоупотреблять, претендуя на заброшенные «slugs», чтобы унаследовать их доверие. Чтобы эта атака увенчалась успехом, единственным предварительным условием является то, что доверенный издатель жертвы указывает на «slug» GitHub, который злоумышленник может заявить, и что репозиторий никогда не использовался для публикации версии пакета в npm.
Как только такой «slug» становится доступным после того, как сопровождающий переименует, передаст или удалит репозиторий, злоумышленник может выполнить следующие шаги:
Подобная атака под кодовым названием SlugFest может быть использована для публикации новой «вредоносной» версии пакета жертвы под законным именем пакета, унаследовав существующую репутацию, количество загрузок и зависимые связи. Это, в свою очередь, может привести к масштабным атакам на цепочку поставок.
ИИ-агенты, работающие на машинах разработчиков, могут еще больше усложнить ситуацию. «Агенты разрешают зависимости самостоятельно, обычно берут последнюю версию и редко проверяют, откуда взят пакет», — заявили в Bloom Security. «Вредоносная версия, опубликованная через восстановленный «slug», загружается и выполняется без участия человека».
Компания по кибербезопасности заявила, что обнаружила более 1500 уязвимых пакетов, которые были загружены в общей сложности более 10 миллионов раз.
Разработчикам, сопровождающим пакеты npm, рекомендуется предпринять следующие действия:
«Атака не требует инсайдерских знаний, кражи учетных данных или состояния гонки», — сказал Майерс. «Единственным предварительным условием является доступность «slug» (в привязке, которая еще не использовалась для публикации), что полностью зависит от гигиены репозитория самой жертвы».
«То, что демонстрирует это исследование, — это то, что сообщество по безопасности неоднократно наблюдало в атаках на цепочку поставок: связь между удобочитаемым идентификатором и тем, что он идентифицирует, является самым важным инвариантом в любой системе доверия. Когда эта связь может быть бесшумно заменена — обычным действием переименования репозитория, а не действием злоумышленника — гарантия доверия рушится».
Это не первый случай обнаружения нетрадиционных векторов атак на цепочку поставок. Ранее в августе Bloom Security также обнаружила, что как Open VSX, так и Marketplace Microsoft VS Code позволяют пакетам расширений ссылаться на несуществующие расширения на торговых площадках.
Метод, известный как «Воскрешение расширений» (Extension Resurrection), может быть использован для угона расширений, уже упомянутых в этих доверенных пакетах, просто путем захвата незанятого пространства имен. Было отмечено 87 пакетов в Open VSX и 677 пакетов в Marketplace VS Code как уязвимые.
«Злоумышленники могли бы захватить эти пустые слоты, опубликовать под ними вредоносный код и автоматически установить его вместе с доверенным пакетом — бесшумно отправляя обновления всем, кто ранее установил пакет», — отметил тогда Майерс. «Поскольку расширения работают с полным доступом к хосту, это фактически равносильно [удаленному выполнению кода], доставленному под видом легитимности».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ravie Lakshmanan
