Уязвимость авторизации с оценкой 9.9 в Azure SRE Agent могла позволить вызывающей стороне наследовать его идентичность

CVE-2026-62830 — это уязвимость, вызванная отсутствием авторизации, в Azure SRE Agent — ИИ-агенте Microsoft для команд обеспечения надёжности Azure, который приоритизирует инциденты, запрашивает телеметрию и, при соответствующей настройке, выполняет восстановительные действия. Microsoft раскрыла её в августе 2026 года и оценила в 9,9 из 10 — критический уровень — по CVSS 3.1. Любой арендатор Azure, использующий этого агента, попадал в область действия уязвимости; в архиве инцидентов нет подтверждённых пострадавших и данных об эксплуатации. Описание уязвимости от Microsoft состоит из одного предложения: «Отсутствие авторизации в Azure SRE Agent позволяет авторизованному злоумышленнику повысить привилегии по сети». Служба была исправлена на стороне сервера, и Microsoft заявляет, что клиентам не нужно было ничего патчить. Полная запись с оценками серьёзности и уверенности находится в Orca AI Incident Archive рядом с соседними инцидентами в этой серии.

Что Microsoft опубликовала, а что опустила

В записи Microsoft Security Update Guide для CVE-2026-62830 указано повышение привилегий в Azure SRE Agent, слабость CWE-862 (отсутствие авторизации), базовая оценка 9.9 и временная оценка 8.6. Вектор — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — описывает сетевую атаку, для которой требуются только низкие привилегии, не требуется взаимодействие с пользователем, и которая приводит к высокому влиянию на конфиденциальность, целостность и доступность. В разделе благодарностей бюллетеня Microsoft приписывает обнаружение исследователю безопасности wtm из Offensi.

Две части этого вектора раскрывают суть. Метрика области действия имеет значение Changed (S:C); в собственной документации Microsoft по метрикам это определяется как случай, когда уязвимый компонент и затронутый компонент различаются и управляются разными органами безопасности. Временные метрики — Unproven exploit code, Official fix и Confirmed, поэтому временная оценка оказывается ниже базовой.

В FAQ рекомендации объясняется, почему существует оценка 9,9 без ссылки для скачивания: «Эта уязвимость уже полностью устранена Microsoft. Пользователям этого сервиса не требуется предпринимать каких-либо действий. Цель этого CVE — обеспечить дополнительную прозрачность». Microsoft помечает продукт как сервис, размещаемый исключительно в облаке, поэтому в записи отсутствуют номер сборки и диапазон затронутых версий.

Таблица эксплуатируемости так же ясна, как и FAQ. Публично раскрыто: Нет. Эксплуатировалась: Нет. Оценка эксплуатации: Маловероятно. Чего в рекомендации нет, так это описания потока «от имени», управляемого удостоверения или runbook’ов. Она также не даёт диапазона версий: CPE — это продукт без версии, а единственная указанная уязвимая версия — прочерк. Всё, что читатель хотел бы знать о механизме, приходится брать из другого источника, а этот другой источник — в основном собственная запись архива.

Что такое агент и почему его идентичность — это то, чего стоит достичь

Azure SRE Agent — это не чат-бот, прикрученный к панели мониторинга. В документации Microsoft по Azure SRE Agent описан агент, который подключается к ресурсам Azure, инструментам наблюдаемости, платформам обработки инцидентов и репозиториям исходного кода, собирает сигналы, сопоставляет сведения о развертываниях, предлагает меры по устранению проблем и — в зависимости от режима запуска, заданного клиентом, — выполняет их. В режиме Review администратор утверждает операции записи; в режиме Autonomous агент применяет их, не ожидая подтверждения. Его возможности расширяются с помощью навыков и runbook-сценариев, операций Azure CLI, пользовательских агентов, инструментов Python, коннекторов MCP и хуков агента.

В той же документации приводится факт, который делает CVE интересным: «Агент аутентифицируется с помощью управляемого удостоверения и работает в рамках управления доступом на основе ролей Azure (RBAC)». Управляемое удостоверение — это удостоверение Entra, назначенное службе, и его возможности в точности определяются его назначениями ролей. Таким образом, полномочия агента являются не свойством кода агента, а свойством ролей, привязанных к этому удостоверению, — и именно эту границу не смогла бы защитить отсутствующая проверка авторизации.

Отдельная техническая публикация — статья HackTricks Cloud о повышении привилегий в Azure SRE Agent — описывает структурную версию этой проблемы, не ссылаясь на CVE-2026-62830. В ней перечислены операции плоскости управления, позволяющие вызывающему управлять агентом — открыть поток, одобрить предложенное исправление, перепривязать конфигурацию агента, переназначить коннектор данных — а результат описывается как confused deputy: вызывающему не нужны разрешения агента, ему нужен лишь способ заставить агента использовать их. Эта статья не посвящена данной CVE, и её не следует воспринимать как подтверждение этой CVE. Она полезна по той же причине, что и оценка: она показывает, где на самом деле сосредоточены полномочия.

Механизм: что описывает архив и что подтверждает поставщик

В записи архива эта уязвимость описывается как сбой в том, что там называется потоком OBO со сменой области действия (Scope-Changed OBO). Поток «от имени» (on-behalf-of) — это обмен токенов, при котором одна служба обменивает учетные данные вызывающей стороны на токен, позволяющий ей вызвать нижестоящую службу от имени этой вызывающей стороны. Если проверка полномочий при таком обмене завершается неудачей, как указано в архиве, нижестоящий вызов может переключиться на собственный управляемый идентификатор агента с областью действия клиента вместо идентификатора вызывающей стороны. Тогда вызывающая сторона с низкими привилегиями, но прошедшая проверку подлинности, наследует разрешения субъекта-службы агента и сможет изменять модули Runbook, телеметрию и инфраструктуру — не только агент, но и каждый ресурс Azure, на который у управляемого идентификатора есть роль.

Это описание согласуется со всем, что Microsoft действительно опубликовала, и его нет в опубликованных материалах Microsoft. Текст поставщика подтверждает три момента: проверка авторизации отсутствовала, вызывающей стороне требуются только низкие привилегии, а последствия пересекают границу полномочий в сфере безопасности. Он не подтверждает обмен токенами, наследование удостоверений или примеры runbook и телеметрии. Источником этих сведений служит запись в архиве, а архив — это вторичный набор данных, а не поставщик.

Поиск независимых репортажей обнаруживает один и тот же абзац более чем в одном месте: заголовок о потоке OBO и радиусе поражения, как оказывается, синдицирован на forkast.news и Yahoo Tech, среди прочих. Синдикация делает такое освещение одним источником, а не несколькими. Ни одно издание, рассмотренное для этой статьи, не опубликовало собственной телеметрии, доказательства концепции или воспроизведения механизма.

Что установлено, что описано и что никогда не утверждалось

Архив оценивает эту запись на A — хорошо документирована, первичные источники согласуются — и не помечает её как спорную. В ней не фиксируется никакого реального ущерба. Эта оценка касается основных фактов записи, и они действительно совпадают в источниках; она не является утверждением о том, что каждое предложение в записи было независимо воспроизведено.

• Подтверждено поставщиком. CVE-2026-62830 затрагивает Azure SRE Agent, относится к CWE-862 (отсутствие авторизации), имеет базовую оценку CVSS 3.1 9,9 и временную оценку 8,6, не требовал действий со стороны клиентов, не был публично раскрыт и не был зафиксирован как эксплуатируемый.

• Установлено на основании независимой отчётности по безопасности и обогащения данных.В обзоре Cisco Talos, посвящённом августовскому Patch Tuesday 2026 года, указана эта CVE с тем же показателем 9.9 и тем же недостатком — отсутствием авторизации, и она отнесена к оценке эксплуатации Microsoft «менее вероятно». Оценка SSVC агентства CISA, зафиксированная через NVD, определяет эксплуатацию как «нет», автоматизируемость как «нет», а техническое воздействие — как «полное». Обогащение данных OpenCVE указывает оценку EPSS 0,00778 и отмечает, что данная CVE отсутствует в каталоге известных эксплуатируемых уязвимостей CISA.

• Описано, но независимо не подтверждено. Сбой обмена токена OBO, наследование управляемого удостоверения агента, а также последствия для ранбука, телеметрии и инфраструктуры взяты из записи архива и из синдицированных вторичных материалов. В рекомендациях Microsoft они не названы. Это наиболее полезная часть записи и наименее документированная её часть.

• Нигде не установлено. Нет данных об эксплуатации, нет пострадавших, нет публичного proof of concept, нет номера сборки и диапазона уязвимых версий. Строка Microsoft об эксплуатируемости — публично раскрыто: нет, эксплуатируется: нет, маловероятно — это ближайшее к отчёту о статусе, что существует.

• Освещение в мейнстримных СМИ отсутствует. Поиск по этой CVE в общих технологических и профильных ИБ-изданиях не дал ни одной статьи от The Register, BleepingComputer, SecurityWeek или Help Net Security. Её публичный след — это рекомендация вендора, базы уязвимостей, сводка Patch Tuesday и синдицированный материал. Для оценки 9.9 это необычно, и это факт о самой записи, а не суждение о риске.

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

Поскольку Azure SRE Agent — это облачный сервис, исправление было применено на стороне Microsoft. Нет обновления, которое нужно установить, нет номера сборки, который можно было бы сверять с инвентаризацией, и нет способа для клиента извне подтвердить, что арендатор был защищён до определённой даты. Позиция Microsoft заключается в том, что никаких действий не требуется, и применительно к самой уязвимости эта позиция верна.

Запись архива добавляет рекомендации, которые не разъясняются в бюллетене: проверяйте назначения управляемых удостоверений, сверяйте RBAC с тем, что агенту действительно нужно, и отслеживайте аномальное повышение привилегий. Эти рекомендации принадлежат архиву, а не являются цитатой из Microsoft.

Практическое следствие вытекает из архитектуры, а не из чьей-либо рекомендации, поэтому относитесь к нему как к выводу. Если полномочия агента — это его ролевые назначения, то устойчивыми мерами контроля являются охват этих назначений и хранение журналов control-plane, которые показали бы их использование. Исправление на стороне сервиса закрывает этот путь; оно не сужает задним числом управляемую идентификацию, которой было выдано избыточное число прав, и не может помочь организации, которая не хранила журналы. И то, и другое — то, что клиент по-прежнему контролирует после закрытия CVE.

Где оно находится в пакете за август 2026 года

Обзор Talos делает сравнение неизбежным. В том месяце в нём также перечислены CVE-2026-59118 в Copilot Cowork — повышение привилегий через ненадлежащую авторизацию с оценкой 9.3 — и CVE-2026-56162 в Azure SQL Database — повышение привилегий с оценкой 10.0. Единственной уязвимостью, которую Talos в том месяце указывает как эксплуатируемую в реальных атаках, не была ни одна из них: это CVE-2026-68820 в Windows AFD для WinSock. Записи о продуктах с ИИ в списке Talos — это ошибки авторизации, и именно такую конкретную форму имеет риск, который документирует эта запись.

Ничто из этого не делает CVE-2026-62830 нарушением безопасности. Это CVE, опубликованный в целях прозрачности, для сервиса, который уже был исправлен; он опубликован, чтобы клиенты могли увидеть, что было не так, и проверить собственные конфигурации. Ценность этой записи заключается в вопросе о конфигурации, который она оставляет после себя: до каких ресурсов могла получить доступ учётная запись агента и заметил бы кто-нибудь, если бы её использовали, — а не в патче, который нужно запланировать.