SlugFest: как npm по ошибке доверял публикацию пакетов чужому имени репозитория

Коротко: 13 октября 2026 года Bloom Security раскрыла уязвимость SlugFest в npm Trusted Publishing — механизме, который позволяет публиковать пакеты прямо из GitHub Actions без ручного ввода токена. Проблема в том, что npm привязывал доверие к адресу репозитория (owner/repo), а не к его постоянному числовому ID. Переименованный или удалённый репозиторий освобождал старое имя, и злоумышленник мог занять его и публиковать новые версии чужого пакета без единой кражи учётных данных. Исследователи насчитали более 1500 потенциально уязвимых пакетов суммарно с 10+ млн загрузок. GitHub выпустил исправление 2 октября 2026 года.

Что такое npm Trusted Publishing и где он подвёл

Trusted Publishing — это схема на основе протокола OIDC: npm доверяет сборке, запущенной из определённого workflow конкретного GitHub-репозитория, и позволяет ей публиковать новые версии пакета без хранения долгоживущего токена доступа. Задумано это было как защита от утечек секретов — именно долгоживущие токены публикации много лет остаются главной причиной атак на цепочку поставок npm.

Загвоздка оказалась в том, по какому признаку npm проверял, что workflow действительно принадлежит «тому самому» репозиторию. Вместо постоянного числового ID репозитория GitHub система сверялась с его человекочитаемым адресом — связкой «владелец/имя» (slug). А этот адрес, в отличие от ID, не закреплён за репозиторием навсегда: его можно освободить, переименовав или удалив репозиторий.

Как работал захват пакета

Механика атаки, которую описала Bloom Security, не требовала взлома:

1. Найти цель. Атакующий искал npm-пакет, чья конфигурация Trusted Publishing указывала на репозиторий, который впоследствии переименовали, перенесли в другую организацию или удалили — старый slug освободился.
2. Занять имя. Злоумышленник создавал на GitHub новый репозиторий с тем же освободившимся адресом owner/repo.
3. Опубликовать вредоносную версию. Поскольку npm всё ещё сверял доверие по имени, а не по ID, сборка из нового — чужого — репозитория проходила проверку Trusted Publishing и могла выпустить новую версию пакета, который злоумышленнику формально не принадлежал.

Масштаб: 1500+ пакетов и фактор ИИ-агентов

По данным Bloom Security, под риском захвата находились более 1500 npm-пакетов с суммарно более 10 млн загрузок — часть из них скачивают свыше 1 млн раз в месяц. Отдельно исследователи отметили, что риск усиливают ИИ-агенты для написания кода: такие инструменты автоматически создают и переименовывают репозитории в рамках своей работы, повышая шанс случайно освободить адрес, который всё ещё привязан к живой публикационной конфигурации npm.

Это не первый инцидент вокруг npm в октябре 2026 года: несколькими днями ранее экосистему уже встряхнул самораспространяющийся вредонос в пакете tensorlake, использовавший легитимный workflow сопровождающего для публикации заражённой версии. SlugFest — другой по механике случай: здесь уязвима не отдельная сборка, а сама логика проверки доверия у платформы.

Как GitHub закрыл уязвимость

Bloom Security сообщила об SlugFest в GitHub ещё 6 июня 2026 года. Исправление вышло 2 октября 2026 года — спустя почти четыре месяца. Решение не меняет саму идею Trusted Publishing, а добавляет страховку на случай зависших настроек:

• конфигурация Trusted Publishing, которая ни разу не использовалась для успешной публикации, теперь автоматически истекает через 48 часов после создания;
• это не даёт злоумышленнику спокойно ждать, пока нужный адрес репозитория освободится и останется «подключённым» к чужому пакету сколь угодно долго.

Публичного списка затронутых пакетов GitHub и npm не раскрывали — проверка велась по внутренним данным платформы.

Что делать мейнтейнерам и всем, кто ставит зависимости

Для темы нашего сайта вывод простой: пакет — это файл с манифестом, и безопасность его публикации зависит не только от того, кто ввёл пароль, но и от того, как платформа технически определяет «доверенный источник». SlugFest показал, что даже без токенов и фишинга слабое звено может быть в самой логике идентификации.

1. Проверьте конфигурацию Trusted Publishing. Если ваш пакет использует эту схему, убедитесь, что репозиторий, на который она настроена, не переименовывался и не удалялся без очистки настройки на стороне npm.
2. Не оставляйте пакет без привязки. Переименовывая или архивируя репозиторий, который публикует npm-пакеты, сразу отключайте или пересоздавайте для него Trusted Publishing — не полагайтесь на 48-часовое окно как на единственную защиту.
3. Фиксируйте версии в проде. Для критичных зависимостей используйте lock-файлы и проверку контрольных сумм — это не остановит захват имени на GitHub, но не даст непроверенной версии тихо попасть в сборку.

Рядовым пользователям веб-приложений отдельных действий не требуется — атака нацелена на разработчиков и инфраструктуру публикации пакетов. Но общий принцип стоит запомнить: безопасность файла или пакета — это не только «кто его подписал», но и «что именно платформа на самом деле проверяет». Базовые правила безопасной работы с файлами и вложениями — в разделе безопасность файлов.

Источники

• WorkOS — SlugFest: The npm Trusted Publishing flaw that trusted names, not IDs
• TheNextWeb — npm Trusted Publishing flaw left 1,500 packages open to attackers
• Security Boulevard — Bloom Security Finds AI Coding Agents Could Amplify the Impact of an npm Publishing Flaw