Исследователи обнаружили 18 вредоносных npm-пакетов, которые маскируются под зависимости из экосистемы Alibaba и устанавливают кроссплатформенный троян удалённого доступа. История неприятна не только для китайского рынка: это ещё одно напоминание, что компрометация одной «тихой» зависимости легко доезжает до рабочего ноутбука разработчика.
Атака встроилась в цепочку зависимостей Alibaba
Один из ключевых пакетов в этой истории — lib-mtop. Его опубликовали ещё в ноябре 2023 года как пустой пакет без полезной функциональности. Затем в марте и апреле 2026 года вышли три обновления, в которых уже появился вредоносный загрузчик: он подтягивал JavaScript-код с удалённого сервера и запускал следующую стадию атаки.
По данным Socket, пока неясно, как именно в пакет попал вредоносный код: речь может идти либо о захвате учётной записи сопровождающего, либо о намеренной публикации заражённой версии. Ещё три пакета, связанные с пользователем ch4ce, выглядели как обёртки и тянули зависимости с приватным пространством имён @ali, то есть явно целились в среду, где уже используют внутренние инструменты Alibaba.
Вредоносный код прятался в нескольких пакетах сразу
Схема не самая лобовая. Загрузчик распределили по нескольким пакетам, чтобы каждый по отдельности выглядел относительно безобидно. После установки один компонент связывался с другими зависимостями и собирал полноценную цепочку заражения уже на машине жертвы.
Одной из низкоуровневых зависимостей исследователи называют smart-config-manager. Она выступала связующим звеном между легитимными и вредоносными пакетами. Дальше скомпрометированный код обращался к удалённой инфраструктуре и получал полезную нагрузку с учётом операционной системы, после чего запускал RAT.
Иными словами, проблема не в одном «плохом пакете», а в том, что вредоносная логика размазана по дереву зависимостей. Такой подход хуже ловится при поверхностной проверке и особенно неприятен в крупных проектах, где никто не читает весь lockfile ради душевного спокойствия.
Риски для разработчиков и компаний
Для русскоязычной аудитории вывод вполне прикладной. Если команда использует китайские SDK, зеркала npm-репозиториев, внутренние пакеты партнёров из Азии или просто тащит зависимости без жёсткой валидации, риск уже не теоретический. Компрометация open source давно перестала быть историей только про GitHub и западные пакеты: атакующие идут туда, где меньше ручных проверок и больше доверия к «служебным» библиотекам.
Минимальный набор действий здесь очевиден: проверить lockfile и историю обновлений зависимостей, пересобрать окружения из чистого состояния, отозвать токены и ключи с машин, где могли устанавливаться подозрительные версии, и включить контроль install-скриптов и новых релизов в CI. Иначе один «вспомогательный» пакет быстро превращается в удалённый доступ к корпоративной сети.
Первоисточник: Socket. Дополнительный пересказ фактов: The Hacker News.
Следующий важный шаг — публикация полного списка затронутых версий и индикаторов компрометации, чтобы команды могли проверить свои сборки без гадания по косвенным признакам.