73 репозитория Microsoft на GitHub были отключены меньше чем за две минуты, и это не выглядит как локальный сбой в отдельно взятой команде. Это атака на цепочку поставок в ее самой неприятной форме: ломается не один пакет, а доверие к привычным компонентам разработки, которые компании спокойно тянут в CI/CD и IDE.
По данным Dark Reading, инцидент развернулся 5 июня: в автоматическом режиме были выведены из доступа 73 репозитория, в основном из Azure-организации Microsoft, после срабатывания механизмов GitHub по нарушениям условий сервиса. Проблема быстро вышла за пределы самой Microsoft, потому что пострадали GitHub Actions, встроенные в чужие пайплайны. Самый заметный пример — Azure/functions-action, который используют для деплоя Azure Functions. Когда GitHub временно отключил этот action и связанный с ним functions-container-action, чужие workflow просто перестали нормально резолвиться.
Здесь важен не только масштаб, но и способ распространения. StepSecurity связала инцидент с Miasma — вариантом червя Mini Shai-Hulud, который уже фигурировал в атаках на цепочку поставок вокруг npm и других open source-экосистем. На этот раз злоумышленники, как пишет издание, не делали ставку на подмену кода в пакетном реестре. Вместо этого они использовали конфигурационные файлы, которые автоматически исполняют код, когда разработчик открывает зараженный репозиторий через AI coding tool или IDE. В списке целей исследователи назвали Claude Code, Gemini CLI, Cursor и Visual Studio Code. Логика у атакующих довольно прозрачная: защитные системы в индустрии уже более-менее научились смотреть на package manager и install hooks, поэтому следующая удобная щель — доверенные конфиги в репозитории, которые никто не ждет увидеть в роли точки входа.
Для Microsoft эта история особенно неудобна потому, что она, похоже, продолжает предыдущий эпизод. 19 мая в PyPI успели опубликовать три отравленные версии официального Python SDK durabletask от Microsoft. Пакет, который обычно набирает около 400 тысяч загрузок в месяц, провисел в таком состоянии примерно 35 минут, после чего был удален. Тогда исследователи StepSecurity писали, что вредоносная начинка включала модульный фреймворк rope.pyz: он крадет секреты и учетные данные, а в отдельных регионах способен разворачивать destructive wiper. Ключевая деталь из новой атаки — вредоносный коммит пришел с того же аккаунта GitHub-contributor, который уже фигурировал в майском инциденте с PyPI-пакетом Microsoft.
Отсюда и главный неприятный вопрос: что именно пошло не так после первой компрометации. У StepSecurity несколько версий. Первая — учетные данные после атаки 19 мая не были полностью отозваны или ротированы. Вторая — тот же аккаунт повторно скомпрометировал сам червь через собственный механизм распространения. Третья — злоумышленники использовали токен другого разработчика, а метаданные автора подделали через Git Data API. Наиболее вероятным сценарием StepSecurity считает комбинацию первых двух вариантов: аккаунт уже однажды попал в радиус поражения, после чего стал удобной точкой для повторного заражения. Для индустрии это звучит как очень знакомая проблема: даже после публичного инцидента компании нередко закрывают дыру на поверхности, но не успевают зачистить весь контур доверия вокруг нее.
Microsoft ответила максимально сдержанно. Компания заявила, что временно удалила часть репозиториев на время проверки потенциально вредоносного контента, а затем восстановила их после ревью. Также Microsoft сообщила, что уведомила небольшое число клиентов, которые могли скачать содержимое из затронутых репозиториев. На вопросы о судьбе конкретного contributor-аккаунта компания, по данным публикации, прямо не ответила. Для внешнего наблюдателя это, мягко говоря, не снимает главный сюжет: речь не о единичной ошибке в одном пакете, а о повторяемом шаблоне, где компрометированный доверенный аккаунт становится транспортом для следующей волны.
Практический вывод для разработчиков и DevSecOps-команд довольно жесткий. Если организация клонировала эти репозитории после 2 июня и открывала их через перечисленные AI coding tools, StepSecurity рекомендует исходить из того, что компрометация уже произошла. Дальше набор мер неприятный, но стандартный: ротация всех секретов и токенов, аудит npm- и PyPI-пакетов, проверка логов на индикаторы компрометации. Отдельно исследователи советуют просматривать клоны репозиториев на подозрительные конфиги AI-агентов и сторонних инструментов, включать branch protection с обязательным review для всех коммитов и ограничивать исходящий трафик из CI/CD runners к внешним доменам управления. Иначе атака на цепочку поставок превращается из репутационного инцидента поставщика в ваш собственный инцидент уже через пару минут после обычного git clone.
История с Miasma бьет по болезненному месту 2026 года: разработка все активнее опирается на внешние actions, пакеты и AI-инструменты, а контуры доверия становятся длиннее и расплывчатее. Если конфигурационный файл в репозитории уже может быть не менее опасен, чем отравленный пакет в реестре, то следующим полем боя станет не только код, но и весь служебный слой вокруг него — от настроек редактора до агентных workflow, которые раньше считались почти «воздухом» и не попадали в модель угроз.