29 мая 2026 года Infosecurity Magazine заново подсветил инцидент с вредоносным npm-пакетом mouse5212-super-formatter, который OX Security описала 27 мая. Пакет крал файлы из рабочей директории Claude, но сам содержал приватный GitHub-токен злоумышленника — это помогло исследователям проследить работу стилера. Для разработчиков главный вывод простой: зависимости из npm нужно проверять так же внимательно, как код, который попадает в продакшен.
Вредоносный npm-пакет маскировался под служебную утилиту
Исследователи OX Security сообщили о пакете mouse5212-super-formatter, опубликованном в npm и представленном как внутренняя утилита для синхронизации архивов. На деле это был инфостилер — вредоносная программа, которая ищет файлы на машине пользователя и отправляет их на удалённую площадку.
Свежая новостная огласка появилась 29 мая 2026 года в Infosecurity Magazine, а первичный технический разбор OX Security был опубликован 27 мая. Поэтому корректнее говорить не о совершенно новом сегодняшнем обнаружении, а о свежем распространении и обсуждении уже раскрытого инцидента в англоязычной ИБ-повестке.
По данным OX Security, пакет был нацелен на директорию /mnt/user-data. Это важная деталь: такая папка используется инструментами Claude для работы с пользовательскими файлами, загрузками, выгрузками и результатами выполнения задач. Если в этой директории лежали конфиги, фрагменты кода, ключи API, заметки или другие рабочие материалы, они могли попасть к оператору вредоносного пакета.
Ошибка с GitHub-токеном раскрыла механику атаки
Самая необычная часть истории — не только сам факт кражи файлов, а ошибка автора malware. В коде оказался жёстко прописанный приватный GitHub-токен. Иными словами, злоумышленник оставил внутри вредоносного пакета ключ, который использовался для доступа к его собственной инфраструктуре.
Это позволило исследователям увидеть, куда уходили украденные данные, и проследить часть цепочки эксфильтрации. OX Security пишет, что наблюдала около семи активных случаев выгрузки данных в репозитории злоумышленника до удаления связанного GitHub-аккаунта.
Механика выглядела так:
| Этап | Действие вредоносного пакета |
| Установка | Пакет запускал вредоносную логику на этапе postinstall |
| Авторизация | Скрипт использовал GitHub-токен из окружения жертвы или встроенный fallback-токен |
| Подготовка | Проверял наличие целевого репозитория и создавал его при необходимости |
| Сбор файлов | Рекурсивно обходил локальную директорию /mnt/user-data |
| Передача данных | Загружал найденные файлы через GitHub Contents API |
| Маскировка | Создавал фальшивый лог сетевых соединений, чтобы поведение выглядело как диагностика |
Для обычного читателя это можно сравнить с вором, который залез в чужой офис, сложил документы в коробку и случайно оставил на месте преступления ключ от собственного склада.
Признаки AI-сгенерированного кода стали частью проблемы
OX Security описывает этот случай как пример «malware slop» — низкокачественного вредоносного кода, который, вероятно, был сгенерирован с помощью AI и опубликован без нормальной проверки. Прямого доказательства, что каждую строку написал именно ИИ, в публичных материалах нет, поэтому важно не превращать это в сенсацию. Корректная формулировка такая: исследователи увидели признаки AI-сгенерированного или AI-поддержанного кода и связали ошибку с низким уровнем операционной безопасности автора.
Смысл новости шире одной неудачной атаки. Современные AI-инструменты снижают порог входа не только для легальной разработки, но и для злоумышленников. Человек без глубоких навыков может попросить модель собрать скрипт, упаковать его в npm-пакет и замаскировать под полезную утилиту. Но если он не понимает базовых правил безопасности, в коде остаются грубые ошибки: токены, лишние комментарии, странная логика, подозрительные пути и неаккуратные следы.
Это не значит, что AI «сам стал хакером». Гораздо точнее другое: AI ускоряет создание кода, а вместе с ним ускоряет и создание плохого, опасного или плохо проверенного кода.
Разработчикам стоит проверить установки и токены
OX Security рекомендовала всем, кто устанавливал mouse5212-super-formatter, немедленно отозвать GitHub access tokens и считать файлы из /mnt/user-data потенциально скомпрометированными. The Register также указывает, что затронуты все версии этого пакета.
Практический минимум для разработчика:
- Проверьте, устанавливался ли пакет
mouse5212-super-formatterв ваших проектах, CI/CD-средах, песочницах и локальных экспериментах. - Если пакет был установлен, отзовите GitHub-токены и создайте новые с минимально необходимыми правами.
- Проверьте, какие файлы могли находиться в
/mnt/user-dataво время установки. - Просмотрите историю доступа к GitHub-аккаунту, репозиториям и package registry.
- Включите secret scanning, если он ещё не включён.
- Не храните ключи API, приватные токены и
.env-файлы в директориях, которые могут обрабатываться AI-инструментами или временными средами без строгого контроля.
Особое внимание стоит уделить postinstall-скриптам. В npm они часто используются легитимно, но именно на этом этапе вредоносный пакет может выполнять код без явного участия пользователя. Если зависимость неизвестна, а её установка запускает сетевые запросы, создаёт репозитории или читает локальные файлы, это красный флаг.
Инцидент показывает новый риск вокруг AI-инструментов разработки
История с mouse5212-super-formatter важна не из-за масштаба. По данным исследователей, пакет набрал 676 загрузок, и не все они обязательно означают реальные установки на рабочих машинах. Гораздо важнее направление атаки: вредоносный пакет был ориентирован не просто на абстрактного JavaScript-разработчика, а на рабочую среду, связанную с AI-инструментом.
Это меняет модель риска. Раньше атаки на npm чаще ассоциировались с typosquatting — похожими названиями популярных пакетов, кражей npm-токенов или заражением популярных зависимостей. Теперь злоумышленники всё чаще смотрят на то, где именно разработчик работает с AI, какие временные папки создают инструменты, куда попадают загруженные файлы и какие данные остаются после сессии.
Для компаний это означает, что AI-инструменты разработки нельзя воспринимать как «личную игрушку программиста». Они становятся частью цепочки поставки ПО: через них проходят исходники, конфиги, тестовые данные, документация, фрагменты инфраструктуры и иногда секреты. Если такая среда заражается зависимостью из npm, последствия могут выйти далеко за пределы одного локального проекта.
Главный урок — проверять нужно не только готовый код, но и инструменты вокруг него
Инцидент с AI-сгенерированным malware выглядит почти комично из-за ошибки с собственным GitHub-токеном, но его практический смысл серьёзен. Низкий порог создания вредоносных пакетов означает, что подобных атак может стать больше, а их качество будет разным: от примитивных и легко обнаруживаемых до гораздо более аккуратных.
Разработчикам и командам стоит усилить контроль над зависимостями, ограничить права токенов, регулярно чистить временные рабочие директории и не запускать случайные npm-пакеты в средах, где лежат чувствительные данные. AI ускоряет разработку, но не отменяет старое правило безопасности: любой новый инструмент в цепочке сборки нужно считать потенциальной точкой входа.
