sckit: в пакеты AI Memory от MemTensor был внедрён бэкдор для кражи учётных данных и промптов агентов

Четыре релиза MemTensor, опубликованные23 сентября 2026 года, содержали один и тот же урезанный Go-имплант, и каждый из них был новейшей версией в своём реестре, пока был доступен. npm-пакет @memtensor/memos-cloud-openclaw-plugin вышел в версии 0.1.21 в 02:23 UTC, 0.1.23 в 03:49 и 0.1.25 в 04:36; пакет MemoryOS вышел на PyPI в версии 2.0.34 в 05:25. Все четыре содержали sckit, который запускается при загрузке шлюза агента OpenClaw, снова запускается при каждом обращении к памяти — при этом ему передаётся текст запроса пользователя в переменной окружения — и в Python-пакете запускается при обычном импорте модуля memos. Затем он прочёсывает домашний каталог в поисках секретов npm, PyPI, GitHub, GitLab, AWS, Vault и SSH и отправляет найденное на серверы под skyleen[.]fr. Socket, StepSecurity, SafeDep и Aikido независимо задокументировали компрометацию в тот же день, и ни один из них не сообщил о доказательствах того, что имплант запускался на реальном хосте. Архив инцидентов Orca AI хранит эту запись полностью, наряду с каждым другим инцидентом в цепочке поставок, который он зарегистрировал, и каждая запись имеет свою степень уверенности и статус ущерба.

Четыре релиза — и публичный отчёт об ошибке между ними

MemOS — это открытый фреймворк памяти от MemTensor для LLM-агентов, а npm-пакет — это коннектор, позволяющий среде выполнения агента OpenClaw читать данные из размещённого сервиса памяти и записывать в него; по данным StepSecurity, тот же пакет также объявляет точки интеграции для сред выполнения Clawdbot и Moltbot. Socket насчитал у репозитория примерно 11 500 звёзд и 1 100 форков на момент публикации. Именно из-за такого положения компрометация привлекла четыре отдельных расследования: как выразилась StepSecurity, это «помещает плагин внутрь процесса, который регулярно обрабатывает пользовательский ввод и может наследовать ценные учётные данные». Под угрозой оказались те, кто установил любой из пакетов, — разработчики на своих машинах, а также CI-раннеры и контейнеры, которые лишь запускали набор тестов.

Последовательность в npm — самая ясная часть записей, потому что метки времени реестра публичны, а несколько компаний зафиксировали их независимо. Отчёт Socket и хронология SafeDep совпадают до минуты: 0.1.21 в 02:23:04, 0.1.22 в 03:45:44, 0.1.23 в 03:49:20, 0.1.24 в 04:33:30 и 0.1.25 в 04:36:58. Версии 0.1.22 и 0.1.24 были чистыми — Socket говорит, что они совпадали с 0.1.20, за исключением строк версий — и полезная нагрузка возвращалась через три с половиной минуты после каждой из них.

Скачок размера — это и есть подсказка. Socket замерил 0.1.20 примерно в 272 КБ в распакованном виде и 0.1.21 в 43,6 МБ, поскольку вредоносные релизы включали шесть статически слинкованных платформенных бинарников примерно по 7,4 МБ каждый. PyPI демонстрирует ту же картину: wheel версии 2.0.34 весил 19 201 772 байта против 951 210 для 2.0.33, согласно Socket.

В 04:17 UTC — за шестнадцать минут до чистой версии 0.1.24 и за девятнадцать до того, как полезная нагрузка вернулась в виде 0.1.25, — пользователь GitHub по имени omeridel открыл issue #173 в репозитории плагина под названием «Вредоносные версии 0.1.21 и 0.1.23 опубликованы в npm — токен публикации, по-видимому, скомпрометирован». В issue отмечается, что на тот момент 0.1.23 была последним тегом, что ни одна из версий не соответствовала ни одному коммиту или тегу в репозитории, и что самый последний легитимный коммит датировался 14 августа. По состоянию на 26 октября 2026 года issue остаётся открытым, и комментариев от сопровождающих нет.

Что делает sckit после загрузки пакета

Ни один из пакетов не использовал хук установки, поэтому обычный совет относительно --ignore-scripts не применялся. Анализ StepSecurity варианта для npm описывает новый файл, lib/sckit.js, экспортирующий лаунчер, который импортируется и вызывается существующим кодом запуска и восстановления памяти плагина. При запуске он порождает отсоединённый .sckit/<os>-<arch>/sckit процесс с stage0 --config64 и полным окружением родительского процесса; при восстановлении он делает то же самое и передаёт очищенный пользовательский запрос через переменную окружения с именем SCKIT_EVENT_TEXT. Socket прямо сформулировал последствие: следовательно, бинарный файл запускается заново при каждом восстановлении.

Вариант из PyPI короче и на практике его труднее избежать. Socket обнаружил, что memos/log.py вызывает триггерную функцию внутри memos/_stage0.py, когда настроено логирование, что 149 модулей вызывают логгер на уровне модуля, и что поэтому обычного импорта модуля memos достаточно, чтобы запустить полезную нагрузку один раз за процесс. Анализ того же пакета от StepSecurity был чисто статическим — он не устанавливал, не импортировал, не собирал и не выполнял его.

Область сбора — весь домашний каталог. SafeDep указывает корень инвентаризации как $HOME, а целевые файлы — как .npmrc, .pypirc, .git-credentials, .netrc, id_rsa, id_ecdsa, id_ed25519, .vault-token, msal_token_cache, access_tokens.json и access_tokens.db, а также переменные среды, имена которых содержат token, secret, password, API key или database URL, а также распознаваемые форматы токенов для GitHub, GitLab, npm, PyPI, Hugging Face, Slack, Stripe, AWS и SendGrid. Записи OSV для двух пакетов, MAL-2026-16476 для npm и MAL-2026-16475 для PyPI, описывают тот же список файлов и добавляют, что протокол управления и контроля (command-and-control) использует CBOR, обмен ключами X25519 и XChaCha20-Poly1305, с подписанными lease и модулями, доставляемыми во время выполнения, — поэтому содержимое модулей никогда не наблюдалось, только загрузчик, который их загружает.

Две детали определяют, что защитник ещё может восстановить. Бинарный файл содержит процедуры самоудаления с названиями scheduleSelfDelete и deleteExecutable, согласно записи OSV, поэтому рекомендация — искать артефакты процессов и сети, а не файлы. А в версии 0.1.25 добавлен lib/tls-trust.js, который в минимальных Linux-системах задаёт SSL_CERT_FILE как встроенный файл с 145 сертификатами центров сертификации, по данным StepSecurity — исправление, направленное на то, чтобы его собственный трафик работал в контейнерах без системного хранилища доверенных сертификатов.

Релизный пайплайн был способом войти.

Реконструкция SafeDep — наиболее подробное описание первоначального доступа, и она указывает на GitHub Actions, а не на украденный пароль реестра. В период между 00:48 и 02:03 UTC аккаунт GitHub, действовавший под именем Memtensor-AI, создал, отправил и удалил ветку с именем sc/release-0.1.21-20260922-cloud пять раз. Коммит 9b97ec6 изменил скрипт рабочего процесса .github/scripts/validate-release-confirmation.mjs так, что тот добавил значение BASH_ENV в $GITHUB_ENV, из-за чего последующие неинтерактивные шаги оболочки подключали предоставленный злоумышленником sckit-publish-bridge.sh перед выполнением собственных команд. Этот мост проверял имя пакета и 150-секундный тайм-аут шага публикации, вызывал сборщик токенов с NPM_TOKEN или NODE_AUTH_TOKEN, удалял себя и завершался с кодом 1 — поэтому публикация не удалась после того, как токен был получен. Первый вредоносный релиз npm появился через двадцать минут после последнего push ветки.

Путь через PyPI использовал тот же трюк против другого конвейера. SafeDep сообщает, что тег v2.0.34 указывал на неподписанные коммиты, которых не было в main, а коммит b52958f, автором которого указан "MemTensor CI Review", добавил шесть бинарных файлов, загрузчик Python и собственный бэкенд сборки под названием sckit_poetry_build. Этот бэкенд записал BASH_ENV, указывающий на _pypi_bridge.sh, в $GITHUB_ENV; мост действовал только внутри обёртки загрузки twine, получил подписанный индекс с хоста skyleen[.]fr, проверил эмиттер с помощью реализации Ed25519, вывел строку-маркер, снял пароль для загрузки и завершился, ничего не загрузив. Примерно два часа спустя коммит 41bf5c7 удалил этот вызов с сообщением "chore: allow native PyPI upload [skip ci]", тег был удалён и воссоздан в течение десяти секунд, а загрузка на PyPI последовала через 62 секунды после этого. SafeDep интерпретирует первый коммит как запуск для захвата токена, а второй — как запуск, позволивший собственному рабочему процессу MemTensor собрать и опубликовать вредоносный пакет с настоящим токеном проекта.

Не все версии событий совпадают в этом отношении. Socket отметила, что npm-релизы поступили с той же npm-учётной записи, что и более ранние легитимные версии, и не содержали gitHead; это она истолковала как признак того, что они были созданы не CI проекта, и заявила, что не может подтвердить, как злоумышленник получил доступ к публикации. SC Media, сообщая о находках Socket 24 сентября, сделала тот же вывод в пользу компрометации учётной записи. Обе версии сходятся в том, что учётные данные для публикации были похищены из релизного конвейера, и расходятся в том, как был создан сам npm-артефакт; никто не опубликовал журналы рабочих процессов, поскольку API GitHub Actions не показывал запусков после 7 сентября, а SafeDep предполагает, что записи были удалены. Как учётная запись Memtensor-AI вообще получила доступ на отправку, неизвестно в обеих версиях; SafeDep считает кражу токена учётной записи вероятной, но неподтверждённой.

Установлено, выведено и отсутствует

Степень достоверности записи — A, и это не оспаривается; здесь стоит быть точным, потому что уверенность относится к тому, что было опубликовано, а не к тому, что она сделала.

• Установлено: содержимое четырёх артефактов, восстановленное путём статического анализа в Socket, StepSecurity и SafeDep; время публикации в npm и последний тег на 0.1.25; скачок размера в обеих экосистемах; коммиты, теги и историю веток в двух репозиториях; инфраструктуру skyleen[.]fr и идентификаторы кампании cloud-openclaw-semi-nuclear и memos-semi-nuclear; а также конфигурацию полезной нагрузки, срок действия которой истекает 22–23 октября 2026 г. согласно Socket и SafeDep.

• Косвенно установлено, что инструмент был написан с помощью языковой модели, о чём SafeDep прямо говорит и называет это выводом; и что украденные токены публикации предназначались для повторного использования, что строка канала конфигурации — "exact-ref-one-use-NPM_TOKEN" — подтверждает, но не доказывает.

• Не установлено:кем был атакующий; исполнялась ли когда-либо какая-либо копия sckit за пределами песочницы; покидали ли какие-либо учётные данные хост; доходил ли какой-либо промпт, введённый в агент OpenClaw, до атакующего; и был ли переопубликован какой-либо нижележащий пакет. Socket и StepSecurity обе работали статически, и StepSecurity заявляет, что в ходе её анализа не наблюдалось ни запуска процессов, ни передачи секретов, ни успешного эксфильтрирования, ни установки рабочих процессов, ни дальнейшей публикации пакетов.

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

Червь, чьё распространение так и не было замечено

Бинарные файлы содержат не только стилер. SafeDep перечисляет функции с именами recursivePublish, prepareRemoteNode, prepareRemotePython и prepareRemoteWorkflow, а также встроенный шаблон GitHub Actions, запускаемый при push, и возможность записывать файл workflow с именем runtime-update.yml в репозитории, доступные импланту. Socket обнаружил строки о кодировании манифестов пакетов и установке файлов репозитория и пришёл к выводу, что бинарные файлы, возможно, способны перепубликовывать пакеты с использованием украденных токенов реестра.

Это конструкция червя. Это не червь, работа которого была зафиксирована. StepSecurity не нашла доказательств того, что эта логика когда-либо использовалась для распространения, а исследовательская записка Cloud Security Alliance от 25 сентября трактует эту возможность как ограниченный потенциал самораспространения, а не как подтверждённое поведение червя. Ряд изданий описал этот случай как первого червя в цепочке поставок, нацеленного на инфраструктуру памяти ИИ-агентов; это описание справедливо как утверждение о конструкции, и отчёты не подтверждают его как утверждение о том, что произошло.

Что изменилось после этого

Реестры очистили в тот же день. При проверке 26 октября 2026 года метаданные пакета npm больше не содержат 0.1.21, 0.1.23 или 0.1.25 среди версий, тег latest указывает на 0.1.24, а последнее изменение пакета было 23 сентября в 11:53 UTC. По-прежнему присутствуют два необычных dist-тега — clean-inverse-0-1-23, указывающий на 0.1.22, и clean-inverse-0-1-25, указывающий на 0.1.24, — отражая два чистых выпуска, которые ненадолго прервали вредоносные. В PyPI MemoryOS 2.0.34 больше нет, а новейшим выпуском является 2.0.33, загруженный 3 сентября 2026 года; за прошедшие с тех пор семь недель новых релизов на PyPI не было.

Неизменной осталась публичная версия проекта. В репозитории не указано ни одной рекомендации по безопасности, GitHub-issue от 04:17 в день инцидента по-прежнему открыт и остаётся без ответа, и ни одна из рассмотренных здесь публикаций не цитирует заявление MemTensor или OpenClaw. Ни один из вредоносных пакетов не имел аттестации происхождения, что, как отмечает SafeDep, устранило единственный сигнал о том, что артефакты были собраны из неожиданного коммита.

Реакция, которая всё же существует, находится на стороне обнаружения: StepSecurity добавила домены управления и контроля skyleen[.]fr в свой глобальный блок-лист, а два пакета отслеживаются в OSV как MAL-2026-16476 и MAL-2026-16475.

Если была установлена затронутая версия

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

• Удалите пакет и закрепите чистую версию — npm 0.1.20, PyPI 2.0.33. StepSecurity предупреждает, что его анализ не установил чистую базовую версию PyPI, тогда как SafeDep и SC Media оба называют 2.0.33 последним хорошим выпуском.

• Ищите командную строку процесса, поскольку исполняемый файл может удалить себя: sckit stage0 --config64, а также переменную среды SCKIT_EVENT_TEXT.

• Удалите каталоги состояния ~/.openclaw/.cache/runtime и ~/.memos/.cache/runtime, а также проверьте репозитории на наличие неожиданного runtime-update.yml рабочего процесса или .sckit/ каталогов.

• С чистой машины смените все учётные данные, доступные из домашнего каталога и окружения процесса: npm, PyPI, GitHub, GitLab, AWS, Vault, SSH, Hugging Face, Slack, Stripe и SendGrid, а также все значения в .env. В первую очередь — токены реестров и систем контроля версий.

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

• Заблокировать skyleen[.]fr и его поддомены и прочитать журналы исходящего трафика за период с 23 сентября.

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