Исходники червя Miasma 10 июня 2026 года ненадолго появились на GitHub через взломанные аккаунты разработчиков. Для open-source это плохая новость не из серии «еще один стилер»: червь Miasma умеет красть учетные данные, захватывать репозитории и пакеты, а затем сам распространяться дальше по цепочке поставок. Для русскоязычных команд, которые живут на npm, PyPI, GitHub Actions и облачных секретах, это означает простую вещь: компрометация одного ноутбука разработчика может быстро выйти далеко за пределы одного проекта.
О публикации сообщает BleepingComputer со ссылкой на исследователей SafeDep. По их данным, код выкладывали в репозитории с говорящим названием Miasma-Open-Source-Release, причем сразу через несколько скомпрометированных аккаунтов. Такой способ публикации выглядит не как случайная утечка, а как намеренный слив инструментария в публичное поле. Параллель тут очевидна: предыдущий червь Shai-Hulud тоже успел засветиться на GitHub, а затем получил новые варианты и более активное применение.
Сама механика Miasma неприятна именно своей автономностью. После заражения машины разработчика фреймворк вытаскивает учетные данные из сборочного окружения, облачной инфраструктуры и хранилищ секретов, а затем использует их для компрометации легитимных репозиториев и пакетов. Дальше зараженные релизы публикуются в экосистемах вроде npm, PyPI и RubyGems, чтобы зацепить уже следующих разработчиков и повторить цикл. Это не просто вредонос, который тихо сидит в системе и тянет токены. Это червь, который превращает доверенные каналы доставки кода в собственную инфраструктуру распространения.
В утекшем коде исследователи увидели, что Miasma вообще не нужен классический сервер управления. Вместо отдельной C2-инфраструктуры он использует GitHub как рабочую площадку. Для защитников это неприятный поворот: активность маскируется под привычные действия в экосистеме, где у разработчиков и так постоянно происходят коммиты, релизы, запуск workflow и обмен токенами между сервисами. Если раньше команда могла надеяться, что необычный трафик на внешний управляющий сервер даст хотя бы повод насторожиться, то здесь атакующий прячется внутри среды, которой разработчики пользуются каждый день.
Список целей у Miasma тоже без лишней скромности. По данным SafeDep, фреймворк собирает креды от облачных провайдеров, CI/CD-систем, менеджеров паролей, Kubernetes и secret stores. Затем эти данные используются для атак на пакеты в npm, PyPI и RubyGems, на GitHub-репозитории, workflow в GitHub Actions и инстансы JFrog Artifactory. Дополнительно червь умеет двигаться в стороны через SSH и AWS Systems Manager. Отдельная деталь, которая хорошо описывает состояние современной разработки: в коде обнаружили логику для отравления конфигураций AI-инструментов для программирования, включая Claude, Gemini, Cursor, Copilot, Kiro и Cline. Если коротко, атакующий идет туда, где у разработчика уже есть доступ, автоматизация и привычка доверять среде.
Отдельно выделяется так называемый dead-man switch. Если Miasma использует украденный GitHub-токен жертвы как канал для вывода данных, он параллельно ставит компонент, который каждую минуту проверяет, жив ли этот токен. Если токен отзывают, запускается деструктивная команда с удалением файлов из домашнего каталога и папки Documents. На Linux этот монитор закрепляется как пользовательский сервис systemd, на macOS — как LaunchAgent, и может оставаться активным до 72 часов. То есть попытка оперативно закрыть дыру может обернуться еще и локальным ущербом на машине разработчика. Это уже не только про кражу секретов, но и про давление на процесс реагирования.
Еще одна важная деталь из утечки — пятиступенчатый конвейер сборки, который генерирует уникальные полезные нагрузки для каждого билда. В схеме используются AES-256-GCM для шифрования встроенных артефактов, рандомизированная обфускация строк, преобразование исходников, обфускация JavaScript и самораспаковывающийся загрузчик с тремя слоями шифрования. За счет случайных ключей и внешнего слоя кодирования каждый новый образец отличается от предыдущего. Для ИБ-команд это плохой сигнал: простые сигнатуры и статический анализ начинают работать заметно хуже, а окно между публикацией вредоносного пакета и его уверенным детектированием может расшириться.
Контекст у этой истории тоже вполне конкретный. BleepingComputer пишет, что Miasma выглядит как развитие Shai-Hulud и уже связывался с атаками на npm-пакеты Red Hat, а также с более недавним инцидентом, затронувшим 73 репозитория Microsoft на GitHub. Это важное уточнение: речь идет не о лабораторном PoC и не о редком штучном инструменте. Перед нами эволюция рабочего класса атак на цепочку поставок, где главная ценность злоумышленника — не одна компания, а доверие экосистемы целиком. Чем больше open-source-проектов завязано на автоматические публикации, CI/CD и облачные секреты, тем выше отдача от одной удачной компрометации.
Для разработчиков и бизнеса вывод здесь довольно приземленный. Во-первых, зависимости нужно фиксировать жестче, а не подтягивать свежие версии по инерции в день релиза. Во-вторых, задержка в несколько дней перед установкой только что опубликованных обновлений перестает выглядеть паранойей и начинает выглядеть нормальной гигиеной. В-третьих, новые сборки стоит прогонять в изолированных тестовых средах, особенно если проект тянет пакеты из нескольких экосистем и активно использует GitHub Actions или внешние артефактные хранилища. И наконец, защита разработческой среды больше не сводится к антивирусу на ноутбуке. Нужно отдельно смотреть на токены, секреты, права workflow, правила публикации пакетов и то, какие инструменты вообще имеют доступ к домашнему каталогу и облачным учетным данным.
Проблема в том, что open-source по-прежнему держится на скорости, доверии и автоматизации, а Miasma бьет ровно по этим трем точкам. После утечки такого кода порог входа для новых атакующих становится ниже: кому-то уже не нужно изобретать собственный фреймворк, достаточно адаптировать готовый. Вопрос теперь не в том, появятся ли новые варианты, а в том, сколько команд успеют пересобрать свои процессы раньше, чем очередной зараженный пакет снова окажется в проде. Подробности первоисточника доступны у .