Две критические уязвимости в Bing Images с оценкой 9,8 по CVSS позволяли запускать код на серверной инфраструктуре Microsoft через специально подготовленный SVG-файл. Для русскоязычной ИТ-аудитории здесь важен не только сам факт RCE у крупного вендора, но и причина: серверный конвейер обработки изображений снова оказался полноценной поверхностью атаки, хотя многие команды до сих пор считают его «технической обвязкой».
Подробности сначала опубликовала XBOW, а затем пересказал The Hacker News. По данным XBOW, исследователи добились выполнения команд от имени NT AUTHORITYSYSTEM на Windows-узлах Microsoft и от имени root на Linux-машинах в том же пуле обработки изображений. Результат повторялся на разных хостах и в разных сетевых сегментах, так что речь шла не о случайно сломанной машине, а о системной проблеме в инфраструктуре Bing Images.
Microsoft присвоила проблеме два CVE: CVE-2026-32194 и CVE-2026-32191. Оба идентификатора получили критический рейтинг 9,8. В карточках Microsoft и NVD указано, что уязвимости исправили на стороне сервиса еще до публикации бюллетеней 19 марта 2026 года, поэтому клиентам ничего патчить не нужно. На момент выхода бюллетеней признаков эксплуатации и публичного раскрытия не было. Технические детали XBOW раскрыла 23 июля 2026 года, после того как Microsoft завершила устранение проблемы.
Два CVE вели в один конвейер обработки изображений
У Bing оказалось сразу два входа в один и тот же опасный путь. Первый, CVE-2026-32194, связан с публичной функцией поиска по изображению: SVG передавался в base64 через поле imageBin на эндпоинт /images/kblob. Второй, CVE-2026-32191, использовал маршрут через поискового робота: атакующий размещал SVG по произвольному URL, после чего передавал этот адрес через параметр imgurl, а bingbot/2.0 забирал файл и отправлял его в ту же обработку.
Ни авторизация, ни cookies, ни пользовательская сессия, ни даже клик жертвы для этого не требовались. С практической точки зрения это почти идеальный набор для интернет-доступной серверной уязвимости.
SVG оказался не картинкой, а способом добраться до shell
Технически история неприятна своей предсказуемостью. Приложение считало, что обрабатывает «картинку», а вспомогательный слой интерпретировал часть этого файла как команду. Вектором стал SVG, то есть не растровое изображение, а XML-документ, который умеет ссылаться на внешние ресурсы. Если дальше в конвейере стоит ImageMagick или совместимый конвертер, а для некоторых форматов у него включены delegates, неподконтрольный контент может попасть в путь, где внешний обработчик вызывается через shell.
Именно так XBOW и дошла до эксплуатации. Поиск по картинке сначала выглядел как «слепой» SSRF: сервер забирает изображение по URL, но пользователю почти ничего не возвращает. Однако часть узлов отвечала ошибкой 500 и при этом все равно успевала скачать и разобрать содержимое. Это подсказало, что ниже по стеку работает отдельный обработчик. Дальше исследователи перебирали поведение разных coders и pseudo-protocols в ImageMagick. Рабочим оказался image reference внутри SVG: ссылка, начинавшаяся с символа pipe, уходила не в чтение файла, а в shell-команду. Для подтверждения XBOW использовала SVG размером в один пиксель, который запускал безвредную команду только на чтение и отправлял вывод на контролируемый сервер.
Артефакты на скомпрометированных машинах выглядели показательно. На Linux-узлах команды возвращали uid=0 и gid=0, то есть процесс шел с root-привилегиями. На Windows-машинах вывод whoami /all показывал запуск от SYSTEM с включенными SeImpersonatePrivilege и SeDebugPrivilege, а systeminfo указывал на Windows Server 2022 Datacenter. По данным XBOW, исследователи ограничились чтением системной информации и не затрагивали пользовательские данные.
Почему это важно не только для Microsoft
Баг уже закрыт, но класс уязвимости никуда не делся. Это тот же тип проблем, что и ImageTragick 2016 года: конвертер изображений, генератор превью или любой другой вспомогательный сервис слишком часто считают безопасной «внутренней кухней», хотя по факту это внешний периметр. Для разработчиков вывод приземленный: если сервис принимает пользовательские изображения или сам ходит за ними по URL, нужно отключать delegates там, где они не нужны, сокращать список допустимых форматов, изолировать обработку в sandbox, убирать избыточные привилегии уровня SYSTEM и root, а исходящий трафик с таких узлов жестко ограничивать. Для заказчиков облачных сервисов это еще один повод задавать поставщику неприятные, но полезные вопросы про sandbox, egress-контроль и обработку недоверенных файлов.
Следующий логичный вопрос для рынка звучит неприятно: сколько команд до сих пор не считают медиаконвертеры и server-side fetch критичными компонентами безопасности. Оригинальный разбор XBOW доступен по ссылке , краткий пересказ и дополнительные детали собрал .