SSRF в Azure MCP Server может привести к утечке токена управляемого удостоверения на URL

Microsoft опубликовала CVE-2026-26118 10 марта 2026 года: уязвимость подделки серверных запросов (SSRF) в Azure MCP Server Tools, пакете, который позволяет ИИ-агентам и клиентам MCP взаимодействовать с ресурсами Azure на естественном языке. Злоумышленник, имеющий возможность взаимодействовать с агентом на основе MCP, мог бы отправить вредоносный URL вместо обычного идентификатора ресурса Azure; сервер затем отправил бы исходящий запрос по этому адресу и, по словам Microsoft, «может включить свой токен управляемого удостоверения» — передавая вызывающей стороне учетные данные, которые она не должна была видеть. Microsoft присвоила уязвимости оценку CVSS 8.8 и присвоила ей уровень Important, а пакеты, содержащие исправление, — 1.0.2 и 2.0.0-beta.17. В рекомендательном бюллетене не зафиксировано ни эксплуатации, ни публичного раскрытия до выпуска исправления, и не зарегистрировано никакого реального ущерба по нему. Этот инцидент — одна из записей в Orca AI Incident Archive, где хранится полная запись с указанными источниками, оценкой серьезности и оценкой достоверности.

Что на самом деле говорится в рекомендации

Запись Microsoft Security Response Center лаконична, и почти каждая опубликованная подробность об этой уязвимости восходит к ней или к ответам Microsoft на несколько уточняющих вопросов. Полное описание: «Подделка серверных запросов (SSRF) в Azure MCP Server позволяет авторизованному злоумышленнику повысить привилегии по сети». Запись CVE зарезервировала идентификатор 11 февраля 2026 года и сделала его общедоступным 10 марта в 14:00 UTC; примечание к выпуску Microsoft и запись NVD обе содержат эту дату. NVD проанализировала запись и опубликовала её в 18:18 UTC в тот же день во второй половине дня. Единственное найденное для этой статьи уведомление регулятора пришло из Марокко: подразделение maCERT при DGSSI включило CVE-2026-26118 в бюллетень от 11 марта 2026 года, указав Azure MCP Server Tools среди затронутых продуктов с собственным уровнем риска «Important», без отдельной оценки и со ссылкой обратно на релиз Microsoft.

Слабость сопоставлена с CWE-918, подделка серверных запросов, а классификация воздействия — повышение привилегий. Базовый балл Microsoft — 8.8 по вектору CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, временная оценка — 7.7 по E:U/RL:O/RC:C — компонент E:U означает, что на момент выставления оценки Microsoft не было известно об эксплойт-коде, а RL:O означает, что официальное исправление было доступно. NVD приводит тот же базовый балл и относит его к высокому уровню; собственная трехступенчатая шкала Microsoft называет его важным.

Два поля важны не меньше, чем оценка. В записи Microsoft указано Эксплуатируется: Нет и Публично раскрыто: Нет. Решение SSVC CISA по записи NVD с отметкой времени 5 марта 2026 г. совпадает в отношении эксплуатации — none — при этом техническое воздействие оценивается как total, а автоматизируемость — no. Модель FIRST EPSS оценила вероятность эксплуатации в следующие 30 дней примерно в 1,0%, что соответствует 62,8-му процентилю, в срезе данных от 3 ноября 2026 г. Это уязвимость, которую обнаружили и исправили, а не та, которая, как известно, использовалась.

Как идентификатор ресурса становится исходящим запросом

Azure MCP Server — это реализация Microsoft протокола Model Context Protocol, интерфейса, который ИИ-агенты используют для вызова инструментов. Его инструменты принимают параметры, предоставляемые агентом, — имя учетной записи хранения, идентификатор подписки, имя базы данных — и преобразуют их в вызовы плоскостей управления и данных Azure. В документации Microsoft сервер описывается как выполняющий аутентификацию через Entra ID с использованием «ваших учетных данных пользователя Azure или управляемого удостоверения», при этом доступ ограничивается управлением доступом на основе ролей Azure.

Уязвимость кроется в том месте, где параметр, который должен указывать на ресурс Azure, вместо этого принимается как URL. Объяснение самой Microsoft: злоумышленник «мог воспользоваться этой проблемой, отправив специально сформированные входные данные инструменту Azure Model Context Protocol (MCP) Server, который принимает предоставленные пользователем параметры. Если злоумышленник может взаимодействовать с агентом на базе MCP, он может передать вредоносный URL вместо обычного идентификатора ресурса Azure». Затем сервер отправляет запрос туда, куда ему указали, а не туда, куда предполагал инструмент.

То, что превращает помеху в повышение привилегий, — это то, что передается вместе с запросом. Microsoft сообщает, что исходящий запрос «может содержать свой токен управляемого удостоверения», что позволяет злоумышленнику заполучить этот токен «без необходимости административного доступа». Токен управляемого удостоверения — это учетные данные на предъявителя: тот, кто им владеет, может предъявлять его службам Azure, на которые авторизовано это удостоверение, пока не истечет срок его действия. Смягчающая часть того же абзаца не менее важна: злоумышленник получает «разрешения, связанные с управляемым удостоверением MCP Server», и, по словам Microsoft, «не получает более широких разрешений на уровне клиента или разрешений администратора; только те, что привязаны к скомпрометированному управляемому удостоверению». Масштаб ущерба определяется тем, что кто-то предоставил этому удостоверению, а на практике это часто больше, чем нужно одному инструменту.

Microsoft не называет затронутый инструмент или параметр, и ни один из источников, рассмотренных для этой статьи, этого не делает. Само это упущение является деталью: в бюллетене описывается класс инструментов — принимающий предоставленные пользователем параметры и поддающийся побуждению к загрузке URL, — а не один конкретный эндпоинт.

Исправление и пакеты, которые его содержали

Это не было обновлением Windows. Azure MCP Server Tools поставляются как пакет NuGet для .NET, пакет npm и пакет Python в PyPI, а исправление представляет собой повышение версии в том из них, который используется в развертывании. В рекомендациях Microsoft указаны затронутые диапазоны: от 1.0.0 включительно до 1.0.2 исключительно и от 2.0.0-beta.1 включительно до 2.0.0-beta.17 исключительно — для дистрибутивов NuGet, npm и PyPI.

Даты в реестре npm показывают, что исправленные сборки находились в реестре до публикации уведомления. Версия 1.0.2 @azure/mcpбыла опубликована 6 марта 2026 года, за четыре дня до того, как CVE стала публичной; 2.0.0-beta.17 была опубликована 6 февраля 2026 года, за пять дней до того, как Microsoft зарезервировала идентификатор CVE, и за месяц до появления уведомления. Как бы ни развивались события внутри Microsoft, исправленный код был написан не в ответ на день публикации. NVD и база уведомлений GitHub совпадают в отношении этих верхних границ. Они немного расходятся в нижней части диапазона PyPI — NVD указывает 2.0.0-beta.1, уведомление GitHub — 2.0.0b14 — это расхождение две записи несут с момента публикации, и оно влияет только на то, насколько далеко назад следует проверять при развертывании Python.

Само уведомление было пересмотрено 20 марта 2026 года, через десять дней после публикации, с примечанием о том, что Microsoft «добавила в таблицу обновлений безопасности продукты, в которых описаны различные методы упаковки, используемые для поставки Azure MCP Server Tools». Иными словами, в первой версии уведомления был указан продукт, но не все каналы его поставки, что важно, когда исправление заключается в «обновлении пакета», а не в «установке этого KB».

Что не установлено

Кто его обнаружил. Ни в рекомендациях Microsoft, ни в записи CVE.org не указан исследователь, сообщивший об уязвимости; поле благодарностей в CVE пусто. Это не доказывает, что кого-то не поблагодарили в частном порядке, а лишь то, что публичной благодарности нет.

Любая эксплуатация. Microsoft не фиксирует ни одного случая, оценка SSVC от CISA согласуется с этим, и ни один источник, рассмотренный для этой статьи, не описывает скомпрометированную учетную запись в реальных условиях. Поле real-harm в записи установлено в false, что с этим согласуется. Низкий EPSS — это прогноз, а не установленный факт, и отсутствие сообщений об инциденте не доказывает, что его не было.

Существует ли публичный эксплойт. Именно здесь вторичное освещение расходится. В посте от марта 2026 года в блоге Blueinfy утверждается, что существуют «публичные proof-of-concept эксплойты, например на GitHub», и предупреждается о «стремительном превращении в оружие», но не приводится ни ссылки, ни полезной нагрузки, ни пошагового руководства, и не демонстрируется сама уязвимость. В данных Microsoft указано, что уязвимость не была публично раскрыта до выпуска патча. Поиск по идентификатору CVE в репозиториях GitHub 4 ноября 2026 года вернул один репозиторий — лабораторию обнаружения Microsoft Sentinel, опубликованную 17 марта 2026 года, а не эксплойт, — а на странице уязвимости Mallory указано, что два кандидата в эксплойты были проверены и отклонены. Утверждение о наличии работающего публичного кода эксплойта на основании имеющихся данных не подтверждено; утверждение о том, что никто не пытался, столь же недоказано.

Подача. Страница на PolicyLayer — сайте вендора со сводками инцидентов — переиначивает CVE-2026-26118 как цепочку неаутентифицированного удалённого выполнения кода, завершающуюся полным захватом тенанта, приписывая это названному исследователю и демонстрации на RSAC 2026. Собственные источники, на которые ссылается эта страница, озаглавлены как SSRF, её даты не согласуются с хронологией CVE, и ни бюллетень Microsoft, ни материал SecurityWeek от 10 марта не описывают выполнение кода. В этой статье версия об SSRF и токене рассматривается как установленная, и формулировка об RCE не повторяется.

Почему токен, а не запрос, является находкой

Подделка серверных запросов — один из старейших классов ошибок в веб-программах, и сама по себе она обычно служит способом добраться до систем, к которым атакующий не может обратиться напрямую. Что делает эту запись достойной сохранения — это учётные данные, прикреплённые к запросу. MCP-сервер по своей конструкции является запутанным заместителем: он хранит идентичность, чтобы агент мог действовать от имени пользователя, и каждый параметр, передаваемый агентом, с точки зрения сервера представляет собой текст, на который может влиять атакующий. Когда один из этих параметров становится пунктом назначения, а не именем, заместитель переносит свою собственную авторизацию на этот пункт назначения.

Документация Microsoft уточняет, где концентрируется этот риск. В ней локальный сервер описывается как «предназначенный строго для использования разработчиками в вашей организации», при этом отдельно публикуются руководства по развертыванию саморазмещённых удалённых серверов в Microsoft Foundry и Copilot Studio — конфигурациях, где обычно используется управляемое удостоверение, а не собственный вход разработчика. Путь кражи токена, описанный в рекомендациях, касается именно управляемого удостоверения. В нём не говорится, что каждая установка была подвержена риску, и не говорится, сколько их было.

Общий урок — тот, которому теперь учит на этом случае Стандарт верификации безопасности ИИ OWASP. В главе AISVS об оркестрации CVE-2026-26118 приводится в числе разобранных примеров, и делается вывод: «Параметры инструментов MCP должны рассматриваться как контролируемые злоумышленником, а исходящие запросы от серверов MCP должны проходить через те же политики исходящего трафика и источника, которые ожидаются для любого другого ввода-вывода, инициируемого агентом». Это рекомендация по мерам контроля, а не вывод об этом инциденте, но это самый конкретный ответ, который кто-либо опубликовал на вопрос о том, что следует изменить.

Что изменилось после

Три вещи, и ни одна из них не драматична. Microsoft выпустила исправленные пакеты во всех трёх экосистемах и обновила уведомление, указав их. Экосистема анализа уязвимостей восприняла это спокойно: низкая оценка EPSS и запись NVD, последний раз изменённая 17 июня 2026 года. А сообщество по стандартам приняло это как учебный пример — более медленная и более долговечная форма реакции, чем патч.

Тем, кто всё ещё использует затронутую сборку, исправление остаётся неизменным и прозаичным: перейдите на версию 1.0.2 или более позднюю в стабильной ветке либо на 2.0.0-beta.17 или более позднюю в предварительной ветке — во всех менеджерах пакетов, которые затрагивает развёртывание. Помимо этого, логика самого рекомендательного документа подразумевает три меры контроля: ограничить, куда сервер может обращаться через исходящие соединения, выдать управляемому удостоверению только те роли, которые действительно нужны его инструментам, и рассматривать любой параметр инструмента, который может стать URL, как враждебный ввод. Ни одна из этих мер не была обязательным условием, чтобы не пострадать от CVE-2026-26118. Каждая из них снижала бы ценность следующей для атакующего.

Как архив классифицирует этот случай

Запись зарегистрирована как уязвимость — нечто обнаруженное, а не то, о чём известно, что оно было использовано, — с уровнем достоверности A, что означает хорошую документированность при согласии первичных источников; она не отмечена как спорная. Поле real-harm имеет значение false, а причастность ИИ подтверждена, поскольку затронутый продукт представляет собой мост между ИИ-агентом и облачной плоскостью управления, а не сервис общего назначения, который просто оказался рядом. Дата записана с точностью до дня — 10 марта 2026 года — без даты окончания, поскольку это единичный момент времени, а не кампания. Регион — глобальный, флаг landmark имеет значение false.

Одно поле читается иначе, чем опубликованная оценка. Критичность в архиве зафиксирована как medium по его собственной шкале; число, которое публикуют и Microsoft, и NVD, равно 8.8 — Microsoft называет его Important, а NVD относит к High. Сводка записи начинается с этих 8.8, и расхождение объясняется разницей в категоризации, а не в фактах.

То, чего не может передать запись, — это насколько эта история состоит из отсутствия. Есть уязвимость, которая отдаёт облачную идентичность всякому, кто запросит её в неподходящей форме. Есть исправление, выпущенное до объявления. Нет указанного первооткрывателя, не назван инструмент, нет подтверждённой эксплуатации и нет способа для постороннего понять, запускало ли какое-либо размещённое развёртывание когда-либо уязвимую сборку, обладая при этом мощной идентичностью. Уведомление точно описывает, что делает уязвимость, и молчит почти обо всём остальном, и это молчание — самое полезное, что можно в нём заметить.