Microsoft supply-chain атака: GitHub, Miasma и AI coding tools

По состоянию на 8 июня 2026 года Microsoft supply-chain атака вокруг Miasma выглядит не как обычное заражение пакета, а как предупреждение для всех, кто открывает чужие репозитории через AI coding tools. По данным StepSecurity, 5 июня GitHub отключил 73 репозитория Microsoft в четырёх организациях после вредоносного коммита в Azure/durabletask. Коммит добавлял конфиги для Claude Code, Gemini CLI, Cursor и VS Code, а payload был рассчитан на кражу credentials при открытии проекта.

Microsoft подтвердила 404 Media более осторожную формулировку: компания временно удалила часть репозиториев, пока расследует потенциально вредоносный контент. Точные границы инцидента пока не раскрыты публично. Поэтому корректная версия такая: исследователи описывают supply-chain атаку на developer workflow, Microsoft подтверждает временное удаление части репозиториев на время расследования, а GitHub-страницы ряда проектов действительно показывали disabled-сообщение.

Supply-chain атака на AI coding tools - это сценарий, где вредоносные файлы в доверенном репозитории запускаются или подталкивают агентный инструмент к действию при открытии проекта. Раньше главный риск часто искали в postinstall, setup.py или публикации пакета в PyPI/npm. Здесь опасная точка сместилась ближе к редактору и агенту: достаточно открыть папку в инструменте, который читает проектные настройки.

Что случилось 5 июня

По версии StepSecurity, malicious commit 5f456b8 был отправлен в Azure/durabletask через ранее скомпрометированный contributor account. Сообщение коммита выглядело как обычная инженерная правка: Switched DataConverter to OrchestrationContext [skip ci]. Но исходный код не менялся. Были добавлены пять файлов: .claude/settings.json, .gemini/settings.json, .cursor/rules/setup.mdc, .vscode/tasks.json и .github/setup.js.

Исследователи считают, что эти файлы должны были сработать в разных средах разработки. Claude Code и Gemini CLI могли подхватить настройки при старте сессии, Cursor - через правило проекта, VS Code - через task-конфигурацию, а .github/setup.js был самим вредоносным JavaScript payload. StepSecurity отдельно подчёркивает, что это уже не классический install-hook: клонирование само по себе безопаснее, но открытие папки в доверяющем инструменте становится точкой запуска.

GitHub после этого отключил 73 репозитория Microsoft в организациях Azure, Azure-Samples, Microsoft и MicrosoftDocs. В список, по данным The Hacker News и StepSecurity, попали репозитории Durable Task, Azure Functions, AI sample apps и отдельные документационные проекты. 404 Media пишет, что среди отключённых были 49 репозиториев, связанных с Azure.

Почему это связано с Durable Task

У этой истории был пролог. 19 мая 2026 года StepSecurity сообщила, что в PyPI появились три вредоносные версии официального пакета Microsoft durabletask: 1.4.1, 1.4.2 и 1.4.3. Тогда атака шла через пакетный реестр: при импорте пакет загружал и запускал credential-stealing payload. Microsoft, по данным StepSecurity, подтвердила компрометацию и удалила вредоносные версии из PyPI.

Июньский эпизод опаснее в другом смысле. Он показывает, что атакующий не обязан ждать, пока разработчик установит пакет или выполнит тесты. Если удаётся записать файлы в репозиторий, поверхность атаки переносится в редактор, агентный CLI и локальный trust prompt. Это уже ближе к теме, которую мы разбирали в материале про взлом LiteLLM на PyPI, но с другой механикой: не registry poisoning, а repository injection.

Что подтверждено, а что пока нет

Почему folder trust prompt стал слабым местом

В мае Adversa описала TrustFall: класс проблем в агентных CLI, где проектные настройки могут запускать MCP-серверы после того, как пользователь принимает folder trust prompt. Исследователи проверяли Claude Code, Gemini CLI, Cursor CLI и Copilot CLI. Детали у инструментов разные, но общий риск похож: доверие к папке может трактоваться шире, чем ожидает разработчик.

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

Именно поэтому Microsoft-инцидент важен шире одной компании. Репозиторий больше нельзя считать пассивным набором исходников. Внутри него могут лежать инструкции для агента, конфиги MCP, правила Cursor, VS Code tasks, GitHub Actions и файлы, которые выглядят как служебный шум. Для атакующего это удобная маскировка: reviewer смотрит на application code, а риск лежит в dotfiles.

Сходная логика уже была в истории про prompt injection в jqwik: опасность возникает не только в модели, а на стыке недоверенного контекста, инструментов и автоматического выполнения. Теперь к этому добавляется supply-chain уровень: вредоносный контекст может прийти из репозитория, который выглядит официальным.

Что проверить командам разработки

Главная практическая мысль простая: конфиги AI coding tools нужно ревьюить как исполняемый код. Не как настройки редактора, не как шум в dotfiles, а как часть цепочки выполнения.

• Проверьте репозитории, которые клонировали или открывали после 2 июня, если они были связаны с Azure Functions, Durable Task или AI sample apps из списка исследователей.
• Ищите неожиданные изменения в .claude/, .gemini/, .cursor/, .vscode/tasks.json, .mcp.json и .github/setup.js.
• Если подозрительный репозиторий открывался в Claude Code, Gemini CLI, Cursor или VS Code, считайте рабочую станцию потенциально скомпрометированной до проверки.
• Ротируйте credentials, доступные с этой машины: GitHub tokens, npm/PyPI tokens, SSH keys, cloud service principals, Kubernetes secrets, Docker configs и переменные окружения.
• Включите branch protection: direct push в main для критичных репозиториев должен быть исключением, а не нормой.
• Добавьте отдельный review gate на проектные конфиги AI-инструментов. Изменение .claude/settings.json или .cursor/rules/ должно требовать такого же внимания, как изменение deployment workflow.
• Не запускайте agentic coding tools на CI runner с production secrets против непроверенных pull request branches.
• Пиньте GitHub Actions на commit SHA там, где это возможно. Mutable tag вроде @v1 удобен, но при отключении или подмене upstream-репозитория зависимость ломается сильнее.

Что с Azure/functions-action

5 июня в Microsoft Learn Q&A разработчики жаловались, что Azure/functions-action@v1 перестал работать, потому что репозиторий был disabled. Модератор Microsoft External Staff ответила, что Azure/functions-action отключён из-за internal management issue, расследование продолжается, а на время проблемы можно использовать Azure CLI, Azure DevOps Pipelines, VS Code deployment, Zip Deploy или Azure Pipelines.

К 8 июня публичная страница github.com/Azure/functions-action снова открывалась. Но это не отменяет урока. Если ваш CI/CD зависит от чужого action по mutable tag, вы зависите от доступности и целостности чужого репозитория. Когда такой репозиторий исчезает или временно блокируется, workflow перестаёт резолвить action. Когда репозиторий скомпрометирован, mutable tag может стать ещё опаснее.

Этот сюжет связан с предыдущей историей про взлом GitHub через VS Code-расширение. Developer surface давно вышел за рамки исходного кода: расширения, actions, IDE settings, агентные правила и package managers образуют одну цепочку доверия. Слабое звено в ней редко выглядит как «взломали продакшен». Чаще это маленький файл, который кто-то привык не читать.

Чего пока нельзя утверждать

• Нельзя писать, что Microsoft раскрыла полный технический отчёт. На момент проверки есть короткий statement для 404 Media и отдельные ответы в Microsoft Q&A.
• Нельзя утверждать, что все отключённые репозитории оставались закрытыми 8 июня. Часть уже могла быть восстановлена.
• Нельзя переносить ответственность на Claude Code, Gemini CLI, Cursor или VS Code как на распространителей malware. Исследователи говорят о злоупотреблении доверенными проектными механизмами.
• Нельзя сводить проблему к одному файлу .github/setup.js. Риск в связке: compromised account, repo config, trust prompt, agent/IDE execution и доступные credentials.

Главное

Microsoft supply-chain атака показывает новый участок риска для команд, которые быстро внедряют AI coding tools. Репозиторий теперь может быть не только кодом для чтения и сборки, но и набором инструкций для агента. Если эти инструкции приходят из скомпрометированного upstream, старое «открыл проект и посмотрел» перестаёт быть безопасной привычкой.

Защита начинается не с запрета AI-инструментов. Нужны обычные, но строгие инженерные правила: минимальные права, review dotfiles, изоляция CI, запрет direct push, пиннинг зависимостей, журналирование процессов агента и быстрая ротация секретов. AI coding tools ускоряют работу разработчика, но они же расширяют то, что считается исполняемой частью репозитория.

Источники и проверка фактов

Факты, даты и статусы страниц проверены 8 июня 2026 года.

• 404 Media: Microsoft Hacked to Deliver Malware to Claude and Gemini Users, 8 июня 2026 года.
• StepSecurity: Miasma Worm Hits Microsoft Again, 5 июня 2026 года.
• The Hacker News: Miasma Worm Hits 73 Microsoft GitHub Repositories, 6 июня 2026 года.
• Microsoft Learn Q&A: GitHub action Azure/functions-action down, 5 июня 2026 года.
• StepSecurity: Microsoft's durabletask PyPI Package Compromised, обновлено 5 июня 2026 года.
• Adversa: TrustFall coding agent security flaw, 7 мая 2026 года.
• GitHub: Azure/durabletask, проверено 8 июня 2026 года.
• GitHub: Azure/azure-functions-host, проверено 8 июня 2026 года.

Читайте также

• Взлом GitHub через VS Code-расширение: риск для dev-команд
• Prompt injection в jqwik: stdout как риск для AI coding agents
• Взлом LiteLLM на PyPI: как хакеры превратили ИИ-библиотеку в кражу паролей