GitHub на короткое время отключил 73 репозитория Microsoft после подозрения на распространение вредоносного кода. Инцидент длился всего 105 секунд, но этого хватило, чтобы у части команд перестали работать CI/CD-пайплайны и деплой в Azure: для русскоязычной IT-аудитории это еще одно напоминание, что атака на чужой open source легко превращается в простой вашего продакшена.
Речь идет о репозиториях из организаций Azure, microsoft, Azure-Samples и MicrosoftDocs, сообщает BleepingComputer. По данным издания, отключение произошло 5 июня 2026 года. Сразу после блокировки GitHub показывал стандартное сообщение о нарушении условий сервиса, а в обсуждениях Microsoft сначала объясняла происходящее как «внутреннюю проблему управления» и параллельно вела расследование.
Самый заметный эффект прилетел не в пресс-релизы, а в рабочие процессы разработчиков. Недоступным оказался репозиторий Azure/functions-action — GitHub Action, который многие используют для деплоя Azure Functions. Как только ссылка на action перестала разрешаться, соответствующие workflow начали падать: CI не мог подтянуть нужный репозиторий, а значит, ломался не код, а сама цепочка поставки этого кода. Это важная деталь: уязвимость в 2026 году все чаще выглядит не как взлом продакшн-сервера, а как исчезнувшая зависимость в чужом GitHub-namespace.
Позже Microsoft вернула все репозитории и заявила, что они считаются чистыми и безопасными для использования. Компания отдельно уточнила, что временно удалила часть проектов, пока проверяла «потенциально вредоносный контент», и уведомила небольшое число клиентов, которые могли скачать содержимое из затронутых репозиториев. Формулировка осторожная, но показательная: даже если инцидент локализован быстро, вопрос для вендора уже не только в том, был ли вредоносный код, но и кто успел его получить за эти секунды или до них.
Следы кампании Miasma и старый долг по очистке
Несколько исследователей связали инцидент с кампанией Miasma, также известной как Shai-Hulud, то есть с атакой на цепочку поставок, а не с разовым сбоем внутри GitHub. Платформа OpenSourceMalware указывает, что репозиторий durabletask в организации Azure уже компрометировали в мае. Более того, там предполагают, что тогдашняя очистка могла быть неполной и злоумышленник получил шанс вернуться. Это предположение в материале не подтверждено Microsoft, но сама связка дат выглядит неприятно: майская компрометация, июньское отключение, повторный удар по тем же зависимостям и инфраструктуре публикации.
Отдельный штрих — история с пакетом durabletask в PyPI. По данным OpenSourceMalware, в мае туда успели протолкнуть три вредоносные версии: 1.4.1, 1.4.2 и 1.4.3. Если эта оценка верна, то перед нами уже не просто инцидент в GitHub-репозиториях, а классический supply-chain сценарий с двумя уровнями риска: компрометация исходников или automation в GitHub и последующая доставка вредоносного содержимого через пакетный менеджер. Для разработчиков это самый неприятный жанр атаки, потому что доверие к известному namespace и знакомому имени пакета становится частью механизма заражения.
Инженер по безопасности Аднан Хан прямо связал июньский инцидент с кампанией Miasma, которая ранее задела 32 npm-пакета Red Hat. Компания Cloudsmith в своем отчете пошла дальше и заявила, что были скомпрометированы GitHub-окружение Microsoft Azure и репозиторий durabletask, а сама цепочка развивалась как продолжение атаки на ресурсы Red Hat. По версии исследователей, злоумышленник сначала получил доступ к GitHub-аккаунту сотрудника Red Hat, затем через сиротские коммиты в внутренние репозитории внедрил минимальный workflow, запрашивавший OIDC-токены GitHub. Дальше начался уже знакомый маршрут: токены, автоматизация, доверенные репозитории, подпорченные зависимости.
Отдельно тревожит выбор целей. Cloudsmith пишет, что Miasma целилась в AI-инструменты для разработки, включая Claude Code, Gemini CLI, VS Code и Cursor. Это не значит, что проблема ограничена миром AI-ассистентов; скорее наоборот. Просто именно такие инструменты сегодня имеют доступ к коду, терминалу, токенам, CI-секретам и привычке разработчика нажимать «разрешить» чуть быстрее, чем следовало бы. А значит, компрометация репозиториев Microsoft встраивается в более широкий тренд: атакующие идут туда, где автоматизация уже получила почти привилегированный доступ к цепочке поставки.
Что это значит для команд, которые живут на Actions и пакетах
Если отбросить громкие бренды, урок здесь довольно приземленный. Репозитории Microsoft отключили всего на 105 секунд, но этот эпизод сразу показал, насколько хрупкой может быть современная разработка, когда сборка, деплой и обновления завязаны на внешние действия, пакеты и SaaS-автоматизацию. Проблема не только в том, что вредоносный код могут подложить. Иногда достаточно, чтобы доверенный репозиторий внезапно исчез, был заморожен на проверку или оказался временно недоступен: ваш pipeline уже стоит.
Практические выводы давно известны, но индустрия упрямо откладывает их «на потом». Зависимости стоит фиксировать, а не тянуть в каждый билд все самое свежее из внешнего мира. Обновления пакетов полезно пропускать через задержку хотя бы в несколько дней, чтобы не становиться первой линией тестирования чужого инцидента. Новые сборки и новые версии зависимостей лучше проверять в изолированных средах, а критичные GitHub Actions — по возможности зеркалировать, пиновать по commit SHA и регулярно ревизовать на предмет лишних прав и неожиданных изменений. Все это звучит не очень романтично, зато куда дешевле, чем разбирать инцидент после того, как зараженный пакет уже попал в production-цепочку.
История с репозиториями Microsoft неприятна именно своей приземленностью. Здесь нет киношного взлома дата-центра и нет миллиардных оценок ущерба, которые так любят в заголовках. Есть куда более реалистичная картина 2026 года: один скомпрометированный аккаунт, один лишний workflow, несколько доверенных namespace, несколько десятков затронутых репозиториев — и дальше по цепочке ломаются пайплайны, пакеты и уверенность команд в том, что «официальный репозиторий» по умолчанию безопасен. Главный вопрос теперь не в том, повторится ли такой сценарий, а в том, сколько компаний еще продолжают строить CI/CD так, будто supply-chain-атаки — это чужая проблема из новостей, а не штатный риск для любой команды с GitHub, Actions и внешними зависимостями.