Облачное хранилище
CVE-2026-62911 — NTLM Relay RCE в Microsoft Exchange

В августе 2026 года Microsoft выпустила исправление для уязвимости CVE-2026-62911, затрагивающей Microsoft Exchange Server 2016, Exchange Server 2019 и Exchange Server Subscription Edition.

Официально Microsoft классифицирует проблему как уязвимость повышения привилегий из-за capture-replay с идентификатором CWE-294. CVSS 3.1 — 8.0 (High). При этом технический анализ цепочки эксплуатации показывает, что проблема может использоваться в атаке NTLM Relay через интерфейс MRSProxy и в определённых условиях приводить к удалённому выполнению кода на сервере Exchange.

Особенно неприятен сценарий для инфраструктур, где Exchange доступен из Интернета и используется NTLM-аутентификация без достаточной защиты Extended Protection for Authentication (EPA).

Какие версии Exchange уязвимы

По данным Microsoft и NVD, уязвимость затрагивает следующие ветки:

ПродуктУязвимые версииИсправленная версия
Exchange Server 2016 CU23ниже 15.01.2507.07215.01.2507.072
Exchange Server 2019 CU14ниже 15.02.1544.04415.02.1544.044
Exchange Server 2019 CU15ниже 15.02.1748.04915.02.1748.049
Exchange Server Subscription Edition RTMниже 15.02.2562.04615.02.2562.046

Исправления были выпущены Microsoft 11 августа 2026 года в составе августовских Security Update. Например, для Exchange Server 2016 CU23 это KB5121576, которое устанавливает сборку 15.01.2507.072.

Проверить текущую сборку Exchange можно командой PowerShell:

Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion

Для Exchange Server 2016 после установки августовского обновления 2026 года должна отображаться версия:

15.1.2507.72

В длинном формате:

15.01.2507.072

При этом Microsoft уже выпустила сентябрьское обновление для Exchange 2016 — сборка 15.01.2507.073, поэтому для актуального состояния системы ориентироваться следует не только на минимальную исправленную версию, а на последнюю доступную Security Update для соответствующей ветки Exchange.

В чём заключается проблема

CVE-2026-62911 связана с неправильной защитой NTLM-аутентификации от атак типа capture-replay / NTLM Relay.

В центре атаки находится компонент Mailbox Replication Service Proxy (MRSProxy).

Его HTTP(S)-endpoint:

/Microsoft.Exchange.MailboxReplicationService.ProxyService

может принимать NTLM-аутентификацию.

Проблема возникает, когда NTLM-аутентификация не защищена механизмом Extended Protection for Authentication (EPA) и не используется channel binding, связывающий аутентификацию с конкретным защищённым каналом.

В результате злоумышленник может попытаться заставить один сервер Windows аутентифицироваться перед ним, перехватить NTLM-аутентификационный обмен и передать его другому сервису Exchange.

Это и есть классическая схема NTLM Relay.

Как выглядит цепочка атаки

Упрощённо сценарий можно представить следующим образом:

        ┌───────────────────┐
        │   Злоумышленник   │
        └─────────┬─────────┘
                  │
                  │ заставляет Exchange
                  │ аутентифицироваться
                  ▼
        ┌───────────────────┐
        │   Exchange #1     │
        │   machine account │
        └─────────┬─────────┘
                  │
                  │ NTLM
                  ▼
        ┌───────────────────┐
        │ Relay listener    │
        └─────────┬─────────┘
                  │
                  │ relay
                  ▼
        ┌───────────────────┐
        │   Exchange #2     │
        │     MRSProxy      │
        └─────────┬─────────┘
                  │
                  │ MRSProxy
                  ▼
        ┌───────────────────┐
        │  выполнение кода  │
        │      SYSTEM       │
        └───────────────────┘

Исследование Tenable описывает цепочку, в которой злоумышленник может использовать механизм принудительной NTLM-аутентификации, например PetitPotam, получить NTLM-аутентификацию машинной учётной записи и ретранслировать её на MRSProxy другого Exchange-сервера.

Почему здесь важен именно MRSProxy

MRSProxy предназначен для операций, связанных с перемещением и миграцией почтовых ящиков.

После успешной NTLM Relay-аутентификации атакующий получает возможность обращаться к функциональности MRSProxy с правами машинной учётной записи.

В описанном исследователями сценарии это позволяет обратиться к внутренним операциям MRSProxy, связанным с работой PST.

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

Если в качестве такого пути используется файл, интерпретируемый IIS как ASP.NET-код, цепочка может закончиться созданием web shell и выполнением команд на сервере.

Именно поэтому технические публикации описывают CVE-2026-62911 не просто как повышение привилегий, а как потенциальную цепочку NTLM Relay → MRSProxy → RCE.

Почему атака считается Pre-Auth

На первый взгляд здесь есть противоречие.

Официальное описание CVE говорит об атакующем с определёнными правами и пользовательским взаимодействием, тогда как исследовательская цепочка позволяет начать атаку без обычной интерактивной авторизации пользователя в Exchange.

Причина в том, что здесь нужно различать:

  • обычную авторизацию пользователя в Exchange;
  • NTLM-аутентификацию машинной учётной записи;
  • возможность злоумышленника инициировать relay;
  • конечные права, которые получает ретранслированная аутентификация.

Поэтому термин Pre-Auth NTLM Relay хорошо описывает практический сценарий атаки, но не является официальным названием CVE.

Что делает атаку особенно неприятной

Здесь сходятся сразу несколько механизмов Windows/Exchange:

  1. NTLM допускает relay при отсутствии необходимых механизмов привязки аутентификации к каналу.
  2. Exchange предоставляет доступный по сети MRSProxy endpoint.
  3. Машинная учётная запись Exchange обладает необходимыми правами для взаимодействия с MRS.
  4. В уязвимой реализации существовала возможность записать файл через соответствующий функционал.
  5. Полученный файл потенциально может быть использован для выполнения кода через IIS.

Таким образом, проблема находится не в одной функции, а возникает на стыке нескольких механизмов безопасности.

Как проверить версию Exchange

На сервере Exchange:

Get-ExchangeServer | Select Name,Edition,AdminDisplayVersion

Например:

Name        : EXCH01
Edition     : Standard
AdminDisplayVersion : Version 15.1 (Build 2507.72)

Для Exchange 2016 CU23:

15.01.2507.072

и выше означает, что августовское исправление для CVE-2026-62911 уже установлено.

Но если доступна более новая Security Update, устанавливать старую исправленную сборку специально смысла нет — следует использовать актуальное обновление.

Microsoft публикует актуальные номера сборок Exchange Server на отдельной странице документации.

Проверка через Health Checker

После установки обновления Microsoft рекомендует запускать Exchange Server Health Checker для проверки состояния сервера и дополнительных действий после обновления. Такая рекомендация присутствует непосредственно в документации Microsoft для августовского Security Update.

Это особенно полезно в инфраструктурах, где Exchange обновлялся не одним сервером или где присутствует несколько версий CU/SU.

Как исправить CVE-2026-62911

Основной способ защиты — установить актуальное Security Update для используемой версии Exchange.

Для Exchange Server 2016 CU23 августовское исправление:

KB5121576

Для Exchange Server 2019 CU14:

KB5121575

Для Exchange Server 2019 CU15 используется соответствующее августовское Security Update Microsoft.

Exchange Server Subscription Edition также получил исправление в августовском обновлении KB5121573.

При этом на сентябрь 2026 года уже существуют более новые сборки, поэтому при планировании обновления лучше ориентироваться на актуальную Security Update, а не устанавливать августовскую версию как конечную. Например, для Exchange 2016 Microsoft указывает сентябрьскую сборку 15.01.2507.073.

Что делать, если Exchange пока нельзя обновить

Обновление остаётся основным способом устранения проблемы.

Однако до установки патча стоит дополнительно проверить инфраструктуру на типичные условия для NTLM Relay:

  • доступность Exchange из Интернета;
  • необходимость NTLM;
  • настройки Extended Protection;
  • использование SMB без защиты от relay;
  • возможность принудительной NTLM-аутентификации серверов;
  • наличие нескольких Exchange-серверов;
  • сегментацию серверной сети;
  • наличие устаревших протоколов и сервисов, использующих NTLM.

Особое внимание стоит уделить Exchange, доступному непосредственно из Интернета.

Если сервер Exchange опубликован наружу и при этом остаётся на уязвимой сборке, отсутствие известных атак в логах не следует считать доказательством безопасности.

Как проверить наличие MRSProxy

Для проверки конфигурации виртуального каталога можно использовать Exchange Management Shell:

Get-WebServicesVirtualDirectory |
    Select Identity,MRSProxyEnabled

Если MRSProxy используется, это ещё не означает наличие уязвимости.

Ключевой вопрос — версия Exchange и наличие исправления, а также конфигурация защиты NTLM/EPA.

Не стоит отключать MRSProxy вслепую: в некоторых организациях он используется для миграций и гибридных сценариев.

Есть ли публичный PoC

На момент подготовки статьи публичная информация об эксплойте уже существует. В базе CVE присутствует ссылка на публичный исследовательский репозиторий, а CISA ADP указывает наличие PoC.

Поэтому CVE-2026-62911 уже нельзя рассматривать исключительно как теоретическую проблему.

При этом наличие PoC не означает, что любой Exchange автоматически эксплуатируем: успешность атаки зависит от конкретной конфигурации, сетевой доступности и условий NTLM Relay.

Можно ли обнаружить эксплуатацию

Имеет смысл искать подозрительную активность вокруг:

  • MRSProxy;
  • NTLM-аутентификации;
  • SMB;
  • необычных обращений к Exchange Web Services;
  • создания новых .aspx файлов в каталогах IIS;
  • появления неизвестных файлов в каталогах Exchange/IIS;
  • неожиданного запуска w3wp.exe с дочерними процессами;
  • подозрительной активности машинных учётных записей;
  • неожиданных NTLM-аутентификаций между Exchange-серверами.

Особенно подозрительно сочетание событий NTLM Relay и последующего появления новых файлов в web-каталогах Exchange.

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

После обновления Exchange стоит выполнить минимальный post-check:

Get-ExchangeServer |
    Select Name,AdminDisplayVersion

Затем проверить состояние служб:

Get-Service *Exchange* |
    Where-Object {$_.Status -ne 'Running'} |
    Select Name,Status

И отдельно проверить доступность MRSProxy:

Get-WebServicesVirtualDirectory |
    Select Identity,MRSProxyEnabled

После этого желательно выполнить Exchange Server Health Checker и убедиться, что обновление установлено корректно.

Итог

CVE-2026-62911 — это уязвимость Microsoft Exchange Server, связанная с NTLM capture-replay и возможностью relay-аутентификации на MRSProxy.

Официально Microsoft классифицирует её как повышение привилегий с CVSS 8.0, однако технический сценарий эксплуатации может привести к удалённому выполнению кода на сервере Exchange.

Для администратора практический вывод простой: безотлагательно ставить обновление до актуальной версии SU (но при обновлении Exchange могут возникнуть и сложности), подробный план такой:

Exchange 2016/2019/SE
        ↓
проверить сборку
        ↓
установить актуальный Security Update
        ↓
проверить Health Checker
        ↓
проверить NTLM/EPA и признаки Relay
        ↓
проверить IIS/Exchange на подозрительные изменения

Если используется Exchange Server 2016, имеет смысл проверить сервер в первую очередь: эта ветка уже находится на завершающем этапе жизненного цикла, а новые уязвимости Exchange продолжают закрываться Security Update. Microsoft указывает для Exchange 2016 CU23 августовскую исправленную сборку 15.01.2507.072 и сентябрьскую 15.01.2507.073.

Полезные ссылки

FAQ

Что такое CVE-2026-62911?

CVE-2026-62911 — уязвимость Microsoft Exchange Server, связанная с authentication bypass через capture-replay. Microsoft присвоила ей CVSS 3.1 8.0 (High).

Какие версии Microsoft Exchange затронуты?

Уязвимы определённые сборки Exchange Server 2016 CU23, Exchange Server 2019 CU14/CU15 и Exchange Server Subscription Edition RTM. Исправления выпущены Microsoft в августе 2026 года.

Может ли CVE-2026-62911 привести к RCE?

Да, технический сценарий через NTLM Relay и MRSProxy может закончиться удалённым выполнением кода. Это описано в исследовании Tenable. Официальная классификация Microsoft при этом — Elevation of Privilege / capture-replay, а не отдельная RCE-классификация.

Нужно ли отключать MRSProxy?

Не обязательно. MRSProxy может использоваться для штатных операций Exchange и миграции. Основным исправлением является установка актуального Security Update, а не бездумное отключение функциональности.

Как проверить, уязвим ли Exchange Server 2016?

Выполните:

Get-ExchangeServer | Select Name,AdminDisplayVersion

Для CU23 версия должна быть не ниже исправленной сборки 15.01.2507.072, а на сентябрь 2026 года актуальная сборка уже 15.01.2507.073.

Нужно ли устанавливать именно августовское обновление?

Нет. Если доступна более новая Security Update для вашей ветки Exchange, следует устанавливать актуальное обновление. Для Exchange 2016 Microsoft уже указывает сентябрьскую сборку 15.01.2507.073.

Облачное хранилище