OpenAPI React скомпрометирована в результате атаки на цепочку поставок npm от Mini Shai-Hulud

28 августа 2026 года в npm появились десять вредоносных версий @7nohe/openapi-react-query-codegen. Согласно предупреждению проекта, при установке они запускали код атакующего на машине разработчика или CI-раннере. Под угрозой оказались секреты GitHub, облачных сервисов и реестров пакетов.

За неделю с 23 по 29 августа пакет скачали 156 752 раза. На вредоносные версии пришлось около 1 900 загрузок, и доступны они были меньше двух суток. В пакетной базе npm также находится 8 зависимых пакетов, у которых есть указание использования вредоносного пакета. Это показывает размер потенциально задетой области, а не число подтвержденных заражений.

CodeScoring завел эти версии в базу 29 августа в 02:20 по Москве, через девять минут после публикации предупреждения GitHub, и еще через две минуты они попали под блокировку в платформе. Все десять помечены как опасные, поэтому у пользователей платформы данные компоненты автоматически блокируются при наличии соответствующей политики безопасности.

Атакующему не понадобилось взламывать учетную запись автора пакета. Ошибка была в workflow публикации. Любой пользователь мог открыть pull request из форка и запустить этот сценарий специальным комментарием. GitHub Actions загружал код из pull request и устанавливал зависимости, хотя одновременно имел право публиковать пакет в npm.

По сути, внешний пользователь на несколько минут получал полномочия доверенного издателя. После атаки мейнтейнер проекта убрал запуск публикации по комментариям, отозвал связанные полномочия и оставил выпуск версий только по тегам.

Вредоносный код запускался во время установки пакета. В части версий запуск был прописан в команде preinstall внутри package.json, которую npm выполняет перед установкой. В других ту же команду спрятали в binding.gyp — конфигурационном файле для сборки нативных модулей с помощью node-gyp. Поэтому проверка только скриптов в package.json не обнаружила бы все зараженные выпуски. Полезная нагрузка искала учетные данные и настройки инструментов разработчика, а затем пыталась распространяться через доступные пакеты и репозитории. Механика похожа на августовскую волну Shai-Hulud, только точкой входа стала не учетная запись мейнтейнера, а небезопасный процесс публикации.

Все зараженные версии при этом получили валидные сведения о происхождении сборки (provenance). Это важная граница такой проверки. Она подтверждает, где собрали и опубликовали пакет, но не доказывает безопасность самого процесса. В данном случае сборка действительно прошла через официальный процесс публикации проекта, который, однако, выполнил код из чужого pull request.

Сейчас основной тег пакета снова указывает на чистую версию 3.0.2, а зараженные релизы удалены из NPM. Удаление пакета из реестра остановит новые установки, но не вернет уже украденные секреты. Командам стоит:

• проверить файлы зависимостей и SBOM по полному списку зараженных версий;

• если пакет устанавливался 28 августа с разрешенными установочными скриптами, пересобрать машину или CI-раннер из чистого образа и отозвать секреты, доступные в этой среде;

• очистить кэш пакетного менеджера и повторить установку с чистой версией;

• проверить автоматические сценарии публикации: в них нельзя исполнять код из pull request внешних участников с правами на выпуск релизов.

Пользователям CodeScoring достаточно один раз настроить блокирующую политику с условием «Зависимость опасна». Пример настройки данной политики можно найти в документации платформы.

Червь Shai-Hulud вернулся в npm и получил настоящую подпись

4 августа в npm вышла новая версия keyv, небольшой библиотеки для работы с хранилищами. Внутри был вредоносный код, и через час он появился в cacheable, flat-cache, cache-manager и остальных пакетах того же автора, а оттуда пошел дальше по чужим учетным записям. Сутки спустя специалисты Aikido насчитали 444 зараженных пакета.

Опознать волну было несложно. Червь складывал краденое в публичные репозитории с описанием «Shai-Hulud: Here We Go Again». Wiz относит образец к тому же семейству, что и прошлогодние.

Атакующий получил доступ к учетной записи мейнтейнера и выпустил зараженные версии от его имени. В них он добавил загрузчик setup.mjs, файл с замаскированным вредоносным кодом и настройку preinstall в package.json. Она заставляла npm запускать загрузчик еще во время обычной установки пакета.  

setup.mjs определял, на какой системе работает машина. Если на ней не было Bun (среды для выполнения JavaScript), то он скачивал ее легитимную версию 1.3.13 из официального списка релизов. Затем через Bun запускался Math_Symbol.js. Этот файл собирал токены, ключи и другие секреты, доступные на машине разработчика или сервере сборки. Используя токены публикации червь выпускал зараженные версии пакетов, которыми мог распоряжаться их владелец. Таким образом червь шел не только по дереву зависимостей, но и по полномочиям мейнтейнеров. Очередной зараженный пакет попадал в следующую среду сборки, получал доступ уже к ее секретам и повторял тот же сценарий.

Интересно то, что зараженные версии попали в реестр с настоящей подписью. Год назад экосистема ответила на первую волну Shai-Hulud внедрением доверенных публикаций, при котором пакет собирается в общем сборочном конвейере, а вместе с ним публикуются сведения о происхождении сборки. На августовских версиях эта проверка проходила, и подмены после сборки действительно не было. Вредоносный код лежал в самом репозитории, поэтому конвейер честно собрал и заверил то, что там было.

Второе наблюдение этой волны — это попытка закрепиться там, куда пакетный менеджер уже не смотрит. Получив доступ к репозиториям, червь дописывал в них служебные настройки редактора и ИИ-агента так, что код запускался при обычной работе с проектом, например при его открытии. Запрет скриптов установки, который npm включил по умолчанию этим летом, обрубает главный путь заражения, но эту ветку он не видит. Она живет в конфигурации инструментов, куда дерево зависимостей не заглядывает.

Заражённые версии из реестра уже убрали, а теги последних релизов откатили. Но для машины, куда пакет успел встать 4 августа, это мало что меняет. Секреты уехали в тот же день и работают, пока их не отозвали.

Как в таком случае защитить цепочку поставки?

Новые версии внешних пакетов лучше вовсе не пускать в сборки в день публикации. Период охлаждения хотя бы на 14 дней дает время заметить подозрительный релиз. Доступ к публичным реестрам стоит пропускать через внутренний репозиторий или прокси, чтобы известная вредоносная версия не попала к разработчикам и в сборочные системы. Подробнее о таких рубежах контроля мы писали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Когда запись об уязвимости уже появилась в базах данных, композиционный анализ помогает найти проекты, сборки и контейнерные образы, где могла оказаться конкретная версия, если не применялся период охлаждения. Дальше важно очистить внутренний кэш, проверить изменения в CI, редакторах и ИИ-агентах, а также отозвать секреты, к которым имел доступ раннер. Удаление пакета из реестра этого уже не сделает.

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях

В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.

В июле 2026 года в суд поступили подробные материалы дела. В документе говорится о восьми играх с вредоносным кодом и примерно 8 тысячах зараженных устройств. Следствие связывает атаку с несанкционированным доступом приблизительно к 80 криптовалютным кошелькам и хищением не менее 220 тысяч долларов. Пока это версия обвинения, а не установленные судом факты.

Игры распространялись через учетные записи разработчиков. По данным следствия, для регистрации использовались похищенные персональные данные — это позволяло злоумышленникам успешно проходить проверки площадки, запрашивающей документы и платежные реквизиты. Затем релизы продвигали через соцсети и сообщения пользователям с крупными криптовалютными активами.

Особенно показателен случай Lampy. Вредоносный код содержала обновленная версия игры, выпущенная в январе 2026 года. Пользователю не требовалось переходить на поддельный сайт или устанавливать программу из неизвестного источника – исполняемый файл доставлялся через привычный механизм обновлений.

Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.

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

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

PEP 752 предлагает закреплять за владельцем как сам префикс, так и новые названия, которые включают префикс и дефис после него. Попытка опубликовать такой пакет без разрешения будет завершаться ошибкой. При этом уже существующие проекты можно не блокировать. Репозиторий вправе разрешить их владельцам выпускать новые версии и после появления защищенного префикса.

Синтаксис имен не изменится, поэтому дорабатывать pip, uv и другие менеджеры пакетов ради обычной установки не потребуется. Вместе с тем в API репозитория появятся сведения о связи проекта с защищенным префиксом. В дальнейшем менеджеры пакетов и прокси смогут учитывать их в собственных политиках.

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

У такой защиты есть довольно четкие ограничения. Право на префикс подтверждает, что издатель может использовать такое имя в конкретном репозитории, но ничего не говорит о безопасности содержимого. Если учетную запись доверенного издателя скомпрометируют или он сам выпустит вредоносную версию, резервирование не поможет. На другой репозиторий выданное право тоже не распространяется.

Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

npm 12 больше не запускает скрипты установки зависимостей без разрешения

npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением. 

8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.

Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.

Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.

Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации: в начале августа 2026 года они потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями, а позднее не смогут напрямую публиковать пакеты. Для автоматической публикации GitHub рекомендует переходить на доверенную публикацию через OIDC или использовать публикацию с ручным подтверждением.

Почему это важно

Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Перед переходом на новую версию командам стоит проверить:

• какие зависимости действительно используют установочные скрипты

• откуда в проектах появляются Git-зависимости и удаленные архивы

• есть ли в CI долгоживущие токены публикации с лишними правами

Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.