144 пакеты Mastra npm оказались скомпрометированы после захвата аккаунта бывшего контрибьютора с правами публикации. Для команд, которые собирают AI-сервисы на JavaScript и TypeScript, это не просто еще один инцидент в open source: вредоносный код срабатывал уже на этапе установки зависимостей, то есть до первого импорта библиотеки и до первого запуска приложения.
По данным The Hacker News, атака затронула пакеты в пространстве имен @mastra/* и получила название easy-day-js. Исследователи Endor Labs, JFrog, SafeDep, Socket и StepSecurity описывают схему как массовую публикацию вредоносных версий через один npm-аккаунт ehindero, который за 88 минут 17 июня 2026 года выпустил более 140 зараженных пакетов. Формально в сами релизы Mastra вредоносный код не вшивали: злоумышленники добавляли в зависимости стороннюю библиотеку easy-day-js, и уже она подтягивала второй этап атаки.
Ключевой момент здесь в том, что речь идет не о маргинальном пакете с десятью установками в месяц. Среди затронутых модулей оказался @mastra/core, который, по оценке Socket, набирает более 918 тысяч загрузок в неделю. Mastra используют для разработки AI-приложений, а такие проекты почти всегда живут рядом с облачной инфраструктурой, API-ключами, токенами доступа, сервисными аккаунтами и секретами CI/CD. StepSecurity прямо называет экосистему Mastra особенно привлекательной целью именно потому, что она стоит на стыке AI-разработки и инфраструктуры. В переводе на нормальный язык это означает простую вещь: зараженный npm install в таком окружении может стоить дороже, чем баг в проде.
Сама цепочка выглядит неприятно профессионально. Пакет easy-day-js, опубликованный пользователем sergey2016 16 июня 2026 года в 07:05 UTC, сначала был чистой и рабочей копией библиотеки dayjs. Вредоносные изменения в него внесли только 17 июня в 01:01 UTC. Такой ход нужен не для красоты: чистая первая версия выглядит правдоподобно, не вызывает мгновенных подозрений и проходит базовый визуальный контроль. Дальше включается классика современных supply chain-атак: через postinstall-hook запускается обфусцированный загрузчик, который отключает проверку TLS-сертификатов, обращается к инфраструктуре злоумышленника по адресу 23.254.164[.]92, скачивает второй этап и запускает его в фоне как отдельный процесс. После этого первый загрузчик старается удалить собственные следы, чтобы расследование шло медленнее и скучнее.
Финальная полезная нагрузка уже не ограничивается банальным «что-то куда-то отправить». Исследователи описывают кроссплатформенный стилер, который умеет собирать историю браузера, вытаскивать данные из более чем 160 браузерных расширений криптокошельков, закрепляться в Windows, macOS и Linux и отправлять собранное на командный сервер 23.254.164[.]123. Дополнительно вредонос может опрашивать C2 и получать новые команды, включая загрузку отдельного модуля по URL, который укажет оператор. JFrog отдельно подчеркивает комбинацию приемов: приманка в виде чистой версии, скрытый загрузчик в postinstall, догрузка полезной нагрузки во время выполнения, фоновый запуск, самоудаление и механизм удаленного расширения функциональности. Для атакующего это почти идеальный набор: маленькое изменение в зависимостях превращается в компрометацию на этапе установки по всей цепочке сборки.
В этой истории есть и неприятный организационный вывод. По данным исследователей, злоумышленники захватили аккаунт ehindero — это легитимный бывший контрибьютор Mastra, у которого сохранился доступ к публикации пакетов. SafeDep отмечает, что нормальные релизы Mastra выходят из CI через trusted publisher flow в npm и сопровождаются аттестациями происхождения по SLSA. Но публикация таких аттестаций не была обязательной: стандартный npm-токен все еще позволял отправить пакет в реестр без provenance. Именно этим и воспользовались атакующие. Для команд это болезненное напоминание, что «у нас уже настроен secure pipeline» не равно «мимо pipeline никто не пройдет». Если права на публикацию висят на старых аккаунтах, а установка пакетов не проверяет подписи и аттестации, защита превращается в бумажный пропуск без турникета.
Практические последствия для разработчиков и бизнеса здесь вполне приземленные. Если рабочая станция, CI-раннер или build-окружение ставили затронутые версии, такие хосты нужно считать потенциально скомпрометированными, а не просто «подозрительными». Исследователи советуют откатиться на безопасные версии, сменить учетные данные и проверить машины на артефакты кампании. В реальности список работ шире: ревизия токенов npm, GitHub, облачных секретов, сервисных аккаунтов, SSH-ключей и всего, что могло лежать в браузере, локальном профиле или переменных окружения сборки. npm уже удалил вредоносные версии у наиболее заметных пакетов и откатил их latest-теги, но это не отменяет главной проблемы: если второй этап уже запустился и закрепился в системе, удаление зараженного пакета из package-lock само по себе ничего не лечит.
История с пакеты Mastra npm снова показывает, как меняется цена ошибки в экосистеме разработки. Раньше компрометация зависимости часто означала риск для приложения после деплоя; теперь достаточно одного запуска установки, чтобы под удар попали машина разработчика, раннер в CI и секреты, которыми держится инфраструктура. Для рынка это плохая, но полезная новость: контроль прав публикации, обязательная проверка provenance и жесткая политика к postinstall-скриптам постепенно перестают быть паранойей безопасников и становятся обычной инженерной гигиеной.