В Azure AI Foundry нашли критическую дыру, которую уже эксплуатируют. Что делать компаниям на M365

7 мая 2026 года Microsoft опубликовал бюллетень безопасности по уязвимости CVE-2026-35435 в Azure AI Foundry. Оценка по шкале CVSS 8.6 из 10, что относит её к категории «критических». Главное. Microsoft признал, что уязвимость уже эксплуатируется в реальных атаках. Патча на момент disclosure не было.

Что такое Azure AI Foundry

Это платформа Microsoft для публикации AI-агентов внутри M365 и Azure. Через неё компании создают агентов для автоматизации: Copilot Cowork (тот, что Microsoft анонсировал в начале мая и который сейчас активно внедряют в среднем и крупном бизнесе), кастомные AI-агенты для конкретных бизнес-процессов, интеграции с Azure OpenAI Service.

Если у вашей компании есть подписка M365 Business или Enterprise, и вы хоть раз использовали Copilot, вы скорее всего касаетесь Foundry, даже если этого не знаете.

Суть уязвимости

Технически это improper access control, нарушение контроля доступа. Атакующий с low-privileged ролью в M365 (это может быть обычный сотрудник или взломанная учётка такого сотрудника) через ошибку в Foundry эскалирует свои права. От минимальных до полного контроля над AI-ресурсами организации. Потенциально, над всей M365-средой.

То есть взломали почту менеджера, через ошибку в AI-агенте вышли на админский уровень всей компании.

Почему это важно

До этого критические уязвимости в AI-агентах были в open-source инструментах. PraisonAI 11 мая, CVSS 7.3, эксплуатация началась через 3 часа 44 минуты после disclosure. n8n 17 мая, CVSS 10.0, аутентифицированный RCE. Cline 13 мая, CVSS 9.7, WebSocket hijacking. JunoClaw 12 мая, CVSS 9.8.

Это были инструменты для технарей. Команды, которые их использовали, обычно понимали риски и держали в изолированных средах.

CVE-2026-35435, другая категория. Microsoft. Azure. M365. Это инфраструктура, на которой сидят сотни тысяч компаний по всему миру и десятки тысяч в России. Категория «AI-agent security» из консультантской прихоти стала операционной необходимостью.

Параллельная уязвимость, которую часто пропускают

В тот же день, 7 мая, Microsoft раскрыл CVE-2026-32173 в Azure SRE Agent (CVSS 8.6). Это information disclosure через unauthenticated WebSocket. Атакующий без авторизации получает данные через эндпоинт, который должен быть защищён.

Эта вторая уязвимость уже патчена. Microsoft выпустил обновление. Но если ваша инфраструктура не обновляется автоматически, она остаётся уязвимой. Стоит проверить, что у вас включён auto-update для Azure SRE Agent.

Что проверить прямо сейчас

5 пунктов, которые можно пройти за 30 минут.

1. Список published AI-агентов в вашем M365. Кажется очевидным, но в большинстве компаний такого списка нет. Сотрудники публикуют своих агентов индивидуально, без согласования с IT. Это и есть основа риска, вы не можете защитить то, чего не знаете. Найти в Microsoft 365 Admin Center → Settings → AI Agents.

2. Минимально необходимые права у каждого агента. Принцип minimum privilege, agent должен иметь доступ только к тем данным и системам, которые ему нужны для работы. Не больше. Типичная ошибка, agent создаётся под админской учёткой «чтобы работал везде».

3. Логи активности агентов за последние 30 дней. Microsoft Defender for Cloud и Microsoft Sentinel собирают эти данные. Насторожить должны: активность ночью и в выходные, запросы из неожиданных географий, резкий рост числа запросов, обращения к данным, к которым agent раньше не обращался.

4. Кто из сотрудников может публиковать новых агентов. По умолчанию это могут делать все. Любой сотрудник с лицензией M365 Copilot. Ограничить эту возможность ролью AI Administrator, базовый шаг гигиены.

5. MFA на всех admin-ролях, связанных с AI. Базовая гигиена, но регулярно нарушается. Все админские учётки, имеющие доступ к Azure AI Foundry и M365 Admin Center, должны быть на MFA, желательно через hardware token или authenticator, не через SMS.

Что делать, если 3+ пункта «не знаю»

Это значит, что в вашей AI-инфраструктуре есть структурные пробелы. Не точечные риски, а слепые зоны на уровне процесса.

Что делать по приоритету.

Сегодня. Ограничить количество published agents до минимума критичных. Всё остальное поставить на паузу до устранения вопросов.

На этой неделе. Провести базовый аудит agents (пункты 1, 2, 4). Если внутренних компетенций не хватает, внешний security-консультант на 4-6 часов работы.

В течение месяца. Настроить мониторинг и логирование, включить MFA везде, ограничить сети.

Когда ждать патч

Microsoft не объявил конкретную дату. Обычно для критических уязвимостей такого класса патч выходит в течение 2-4 недель после первого disclosure. Это значит, что окно «без патча» это конец мая или начало июня. На это время режим повышенной осторожности с published agents.

Если у вас 3+ пункта «не знаю», пишите в Telegram, разберу ситуацию.