Атакующий тихо залил вредоносные версии двух легитимных пакетов MemTensor в npm и PyPI, и каждый, кто установил не ту версию, отдал свои облачные ключи, токены реестров, доступ к исходному коду и секреты разработчика. Пейлоад — это стилер на Go под названием sckit, и самое неприятное в том, что он ведёт себя как червь: несёт в себе шаблоны для переустановки самого себя в другие npm-пакеты, Python-пакеты и workflow GitHub Actions. Это не «опубликовали плохой пакет». Это атака на цепочку поставок, которая пытается продолжать распространение через каждого, к кому попадает.

Метод доставки, то есть кража собственных публикационных токенов проекта, становится стандартным сценарием. Если сборка или деплой вашего сайта касается npm или PyPI, изучите индикаторы ниже, проверьте себя сегодня и не полагайтесь на то, что аудит исходного кода для вас уже когда-то закрытая тема.

Что было скомпрометировано

Отравлены две реальные библиотеки MemTensor в обеих экосистемах. Конкретные версии важны, потому что вредоносны не все релизы:

npm: @memtensor/memos-cloud-openclaw-plugin версии 0.1.21, 0.1.23 и 0.1.25 вредоносны. Версии 0.1.22 и 0.1.24 чистые. Обратите внимание на схему: атакующий чередовал вредоносные и чистые релизы, и это осознанный способ проскочить мимо тех, кто считает, что «последняя версия всегда в порядке».
PyPI: MemoryOS версии 2.0.34. Проект сейчас помещён на карантин в PyPI.

npm-пакет — это плагин MemOS Cloud, который связывает рантайм агента OpenClaw с сервисом памяти, а также объявляет точки интеграции с рантаймами Clawdbot и Moltbot. В npm скрытый Go-пейлоад срабатывает при старте шлюза агента и заново каждый раз, когда плагин обрабатывает событие recall из памяти. Хуже того, лаунчер передаёт окружение хост-процесса, а во время recall и сам текст промпта пользователя напрямую вредоносному бинарнику. На стороне PyPI всё ещё прямолинейнее: статически слинкованный Go-бинарник запускается в момент импорта модуля memos в приложение. Никакого особого триггера, просто импорт, и вы его уже выполняете.

Что крадёт sckit

После запуска sckit — это кроссплатформенный сборщик учётных данных под Windows, Linux и macOS. Он охотится ровно за тем, что обычно валяется у разработчика или в CI-джобе, и отправляет добычу на внешний сервер по адресу skyleen[.]fr. По данным исследователей, разобравших его, в числе целей:

Файлы учётных данных: .npmrc, .vault-token, id_ecdsa, credentials.db, access_tokens.json и stored_tokens.
Переменные окружения, сигнализирующие о секретах: всё, что указывает на токены, пароли, API-ключи, приватные ключи, сессионные cookie и строки подключения к базам или брокерам сообщений, включая NPM_TOKEN и PYPI_API_TOKEN.
Именованные креды: ключи доступа AWS, токены GitHub и GitLab, токены npm и PyPI, а также ключи Hugging Face, HashiCorp Vault, Slack, Stripe и SendGrid, и JWT.

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

Как атакующий проник: через собственный релиз-пайплайн проекта

Вот деталь, над которой стоит задуматься каждой команде. Атакующий не фишил пароль мейнтейнера. По данным анализа цепочки поставок, публикационные токены MemTensor он получил прямо из релиз-пайплайнов GitHub Actions проекта, пушая коммиты, которые заставляли workflow отдать npm- или PyPI-токен.

Иными словами, автоматизация CI/CD, существующая для того, чтобы делать релизы безопасными и повторяемыми, сама стала тем, что слило ключи от всего. Релизный workflow с публикационным токеном в окружении — это высокоценная цель, и если атакующий может влиять на то, что этот workflow выполняет, он может заставить его выдать токен. Это тот же класс слабости, что раз за разом всплывает в инцидентах с цепочкой поставок: чрезмерно привилегированная автоматизация, держащая долгоживущие публикационные креды — именно такие цепочки и ловит регулярный DevSecOps-аудит CI/CD, а не разовая проверка кода.

Почему ворм-поведение не даёт отмахнуться

sckit — это не пассивный стилер, который один раз собрал данные и слил. Анализ показывает, что он способен саморазмножаться через GitHub и прямой публикацией в npm и PyPI. Он собирает учётные данные с машин разработчиков и из CI-джоб, получает подписанные задачи с сервера управления (C2) и несёт шаблоны для установки себя в npm-пакеты, Python-пакеты и workflow GitHub Actions.

Сложите эти части, и получите механизм: заразить разработчика или CI-раннер, украсть их публикационные токены, затем этими токенами отравить следующий набор пакетов, который заражает следующий набор жертв. На данный момент неясно, попали ли под распространение пакеты помимо MemTensor, и именно эта неопределённость и есть проблема червя. «Пока мы знаем только про MemTensor» — это не то же самое, что «оно остановилось на MemTensor».

Что делать прямо сейчас

Вредоносные npm-версии на момент публикации всё ещё были доступны для скачивания, так что это не ситуация «подождём, пока рассосётся». Конкретные шаги:

Запиньте на заведомо безопасный baseline. Для npm-пакета пин на 0.1.20. Для PyPI-пакета пин на 2.0.33. Не берите просто «latest», учитывая, как атакующий чередовал чистые и вредоносные релизы.
Проведите ротацию всех засвеченных секретов. Если любая затронутая версия коснулась машины или CI-джобы, считайте сгоревшим всё, до чего можно дотянуться из этого окружения. Ротируйте токены npm и PyPI, ключи AWS, токены GitHub и GitLab, токены Vault, SSH-ключи и любые из сторонних ключей выше. Именно ротация, а не только отзыв, потому что вы не знаете, что уже успели использовать.
Убейте любой запущенный процесс sckit на затронутых хостах. Если нет уверенности, что нашли всё вручную, это ровно та зачистка, которую делает наш incident response на скомпрометированной инфраструктуре.
Заблокируйте skyleen[.]fr и все его поддомены на DNS и egress-файрволе, чтобы ещё не найденный имплант не смог достучаться до управляющего сервера.
Проведите аудит публикационных токенов CI/CD. Вот настоящий урок. Проверьте, держат ли ваши релизные workflow долгоживущие токены npm или PyPI, насколько узко эти токены заскоуплены и может ли недоверенный коммит или pull request влиять на то, что выполняет workflow с этими токенами. Переходите на короткоживущую или OIDC-публикацию там, где это возможно — а сам пайплайн стоит хотя бы раз прогнать через полноценный пентест, а не считать безопасным по умолчанию.

Итог

Компрометация MemTensor — это чистая иллюстрация того, куда сместился риск. Уязвимая поверхность — это уже не только ваш продакшен-сервер, это весь путь, который проходит код, прежде чем туда попасть: пакеты, которые вы тянете, машина, на которой собираете, и автоматизация, публикующая от вашего имени. Один отравленный зависимый пакет, установленный однажды, способен одним движением выкачать креды, дотягивающиеся до вашего облака, репозиториев и деплой-пайплайна, а этот ещё и пытается воспроизводиться через те же самые креды. Мы уже разбирали похожую логику атаки на примере фейкового npm-пакета под видом bug bounty программы Twilio: цель та же — токены и доступ, только MemTensor пошёл на шаг дальше и научился распространяться сам. Пиньте версии, ротируйте всё, что было засвечено, блокируйте домен эксфильтрации и относитесь к публикационным токенам CI как к тем самым коронным драгоценностям, которыми они и являются.