Вредоносный npm-пакет охотился за файлами Claude

Источник: The Hacker News — https://thehackernews.com/2026/05/malicious-npm-package-stole-files-from.html

npm-пакет нацелился на локальные файлы Claude#

Исследователи OX Security нашли вредоносный npm-пакет, который пытался украсть файлы из каталога, используемого AI-инструментом Claude от Anthropic. Пакет назывался mouse5212-super-formatter, был опубликован в npm и, по данным отчета, на момент публикации все еще был доступен для скачивания.

Ключевая деталь — путь /mnt/user-data. OX описывает его как специальный каталог, который Claude использует в фоне для загрузок и результатов работы. На практике там могут оказаться именно те материалы, которые пользователи передают AI-ассистенту для обработки: документы, код, сгенерированные файлы, артефакты рабочей среды и другой локальный контекст.

Это была не фишинговая страница в браузере и не поддельная форма входа. Атака срабатывала при установке пакета. Вредоносный код запускался на этапе npm postinstall — там, где многие легитимные пакеты действительно выполняют установочные скрипты. Класс атаки знакомый, но по-прежнему рабочий: разработчик или система автоматизации ставит пакет, похожий на утилиту, а сам процесс установки становится точкой выполнения кода.

По словам OX, пакет выдавал себя за внутреннюю утилиту «archive deployment sync». Легенда выглядела буднично: проверить или инициализировать GitHub-репозиторий, снять легкий снимок сетевого статуса и синхронизировать файлы рабочей области в удаленное дерево отслеживания. Такое описание достаточно похоже на обычный developer tooling, чтобы не выглядеть абсурдно с первого взгляда.

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

GitHub использовали как канал утечки#

Вредоносный код пытался войти в GitHub с access token, найденным в окружении жертвы. Если такого токена не было, по данным OX, использовался жестко прописанный fallback-токен. После этого GitHub становился транспортом и хранилищем для украденных файлов.

Выбор не экзотический. Трафик к GitHub обычен на машинах разработчиков, CI-раннерах и в build-средах. Инструмент, который обращается к GitHub во время установки, может не привлечь внимания, особенно если пакет заранее заявляет, что занимается синхронизацией репозитория.

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

Заявленное число скачиваний — 676. К этой цифре стоит относиться осторожно. Счетчики npm не равны числу успешных компрометаций. В них могут входить автоматические зеркала, сканеры, повторные загрузки, неудачные установки или активность исследователей безопасности. Источник не устанавливает, сколько реальных систем выполнили пакет и на скольких из них в целевом пути были чувствительные файлы Claude.

Связанный с кампанией аккаунт GitHub на момент публикации уже был недоступен. По данным OX, его создали 26 мая 2026 года, всего за несколько часов до загрузки первой вредоносной версии пакета в npm. Такой короткий интервал указывает скорее на одноразовую операцию, чем на долго развиваемую developer persona.

Небрежная OPSEC тоже важна#

Одна деталь особенно заметна: пакет, как утверждается, раскрыл сведения о GitHub-аккаунте, включая его private token. Это слабая операционная дисциплина. И она вписывается в более широкий паттерн, который начинают видеть команды безопасности: менее опытные акторы теперь могут быстрее собирать рабочий malware, но скорость не делает их аккуратными.

OX предположила, что атакующий мог использовать AI для генерации malware и при этом провалил базовую operational security. Это правдоподобно, но по публичным фактам не стоит делать слишком сильный вывод. Доказательства лучше поддерживают формулировку «небрежный malware с признаками, совместимыми с AI-assisted development», чем уверенную атрибуцию кода как сгенерированного AI.

Более полезный вывод — структурный. npm уже дает атакующим канал распространения, доверие к зависимостям, выполнение кода при установке и доступ к средам разработчиков. AI-assisted coding может снизить усилия, нужные для создания вредоносного пакета, но сама атака не требовала нового exploit. Она повторяет старую схему supply chain: опубликовать пакет, запустить script, собрать файлы, вывести их через доверенную платформу.

Нацеленность на Claude делает инцидент острее. AI-инструменты превращаются в концентраторы рабочей области. Пользователи загружают туда исходный код, контракты, логи, экспорты данных, исследовательские заметки, скриншоты и внутренние черновики. Если локальный каталог ассистента предсказуем и доступен для чтения, malware не обязан глубоко понимать сам AI-продукт. Ему достаточно знать, где оказываются полезные файлы.

Что проверить защитникам#

Командам, которые используют npm и AI-инструменты для кода или документов, стоит смотреть на этот случай как на риск для рабочих станций и build-сред, а не только как на проблему реестра npm.

Практические проверки:

• Поискать mouse5212-super-formatter в package manifests, lockfiles, install logs, shell history и CI logs.
• Проверить npm install activity около окна публикации пакета, если логи доступны.
• Проверить неожиданное создание GitHub-репозиториев, особенно через developer tokens или automation tokens.
• Просмотреть использование GitHub-токенов, scopes и недавнюю API-активность.
• Ротировать все GitHub-токены, которые могли быть раскрыты в окружениях, где пакет был установлен.
• Проверить системы на неожиданный доступ к /mnt/user-data или эквивалентным рабочим путям Claude.
• Считать файлы, загруженные в рабочие области Claude, потенциально чувствительными локальными данными, а не одноразовым cache.

Главная мера — не одна запись в blocklist. Заблокировать этот пакет нужно, но устойчивый риск в другом: выполнение кода при установке сочетается с широким доступом к файловой системе и токенам. Вредоносному пакету не нужны права администратора, если у текущего пользователя уже есть доступ к полезным файлам и учетным данным.

Для машин разработчиков и CI-сред сложные вопросы касаются настроек по умолчанию:

• Каким установкам разрешено запускать lifecycle scripts?
• В каких окружениях GitHub-токены доступны произвольным шагам установки пакетов?
• Какие каталоги AI-рабочих областей читаются обычными инструментами?
• Какие исходящие направления настолько нормальны, что в них легко спрятать exfiltration?

Ни один из этих вопросов не новый. AI-инструменты просто повышают ценность локальных каталогов, которые атакующие будут проверять первыми.

Чего не стоит утверждать сверх фактов#

Публичный отчет не доказывает массовую компрометацию. 676 скачиваний — это сигнал, а не счетчик жертв. Недоступный GitHub-аккаунт ограничивает независимую видимость того, что было получено, сохранено или удалено. Источник также не показывает, что при каждой установке в целевом каталоге были данные Claude.

Пока рано называть это сложной атакой AI-эпохи. Механика обычная. Маскировка пакета обманная, но не тонкая. OPSEC выглядит слабой. Это не делает инцидент безобидным; наоборот, тревожит по-другому. Если malware низкого качества все равно может добраться до файлов AI-рабочей области через публичный package registry, порог для полезной кражи низкий.

Главный урок простой: AI-рабочие области теперь часть attack surface разработчика. Установки пакетов, lifecycle scripts, локальные каталоги ассистентов и GitHub-токены на многих машинах находятся рядом. Атакующим не нужно взламывать AI-модель, чтобы украсть то, что пользователи ей передали.