Специализированный стартап XBOW, занимающийся автономным поиском уязвимостей, обнаружил в поисковике изображений Bing дыру, которая позволяла выполнять команды с правами NT AUTHORITY\SYSTEM на Windows-серверах Microsoft и с правами root — на линуксовых машинах той же инфраструктуры. Причём проблема воспроизводилась не на одном сервере, а на множестве хостов и в разных сетевых диапазонах — то есть речь шла о системном дефекте всего слоя обработки изображений Bing, а не о случайно забытой конфигурации на отдельной машине.
Обнаружили баг тихо, отчёт ушёл в Microsoft напрямую, без публичной огласки. CISO компании XBOW Нико Уайсман, который и написал итоговый разбор, сформулировал суть проблемы одной фразой: «Приложения относятся к обработчикам изображений как к сантехнике. Атакующие относятся к ним как к парсерам». Microsoft исправила обе уязвимости на своей стороне ещё до публикации официальных сообщений — 19 марта появились соответствующие advisory, и в тот момент ни эксплуатация, ни публичное раскрытие информации нигде не фиксировались. Полное описание механики эксплойта XBOW выпустила только 23 июля — задержка была сделана по просьбе Microsoft, чтобы дать время на устранение проблемы. Издание The Hacker News проверило статус записей CVE 24 июля: там всё ещё значилось «нет публичного раскрытия» и «не эксплуатировалось» со стороны Microsoft. Пользователям Bing делать ничего не нужно — исправление полностью серверное, никаких патчей на стороне клиента не предполагается.
Уязвимостей оказалось две, и обе получили максимальную оценку критичности — 9.8 по шкале CVSS. Первая, CVE-2026-32194, классифицируется как командная инъекция (CWE-77) и эксплуатируется через публичную функцию «Поиск по изображению»: атакующий кодирует SVG-файл в base64 и отправляет его в поле imageBin по адресу /images/kblob. Вторая, CVE-2026-32191 — это инъекция ОС-команд (CWE-78) через краулерный маршрут: злоумышленник просто размещает SVG где угодно в сети и передаёт ссылку на него через параметр imgurl, а бот bingbot/2.0 сам скачивает файл и прогоняет его через тот же уязвимый конвейер обработки. Важная деталь — ни одна из двух дыр не требовала ни аутентификации, ни куки, ни сессии, ни какого-либо клика пользователя.
С технической точки зрения обратный поиск по изображению в Bing по сути является слепой SSRF-атакой: сервер сам обращается по указанному URL за картинкой, и никакие данные напрямую клиенту не возвращаются. Зацепка обнаружилась случайно — некоторые воркеры отдавали браузеру HTTP 500, но при этом продолжали загружать и обрабатывать изображение на своей стороне. Это и стало сигналом, что где-то за фасадом ошибки происходит реальная работа с файлом. Корень проблемы оказался классическим: пакеты конвертации изображений, совместимые с ImageMagick, передают неподдерживаемые форматы во внешнюю программу-делегат, вызываемую через shell. Делегатный слой оставался включённым, и ссылка на изображение, начинающаяся с символа вертикальной черты «|», уходила не как имя файла, а прямиком в командную оболочку. Полезная нагрузка представляла собой SVG размером в один пиксель со встроенной ссылкой, которая запускала команду на воркере и через curl отправляла результат на сервер, контролируемый XBOW.
Подтверждение эксплуатации получили классическим для offensive security образом — через внеполосные (out-of-band) данные. Линуксовые воркеры вернули uid=0 и gid=0, то есть полный root. На Windows команда systeminfo показала Windows Server 2022 Datacenter, а whoami /all выдал включённые привилегии SeImpersonatePrivilege и SeDebugPrivilege — набор прав, который открывает прямую дорогу к повышению привилегий до уровня системы. Листинг директорий подтвердил, что выполнение происходило именно внутри мультимедийных компонентов обработки изображений Bing. В XBOW подчёркивают, что использовали только безобидные команды для чтения информации и не трогали данные клиентов.
Путь к финальному эксплойту занял десятки проверок. Исследователи тестировали разные псевдопротоколы ImageMagick: label: просто рендерил переданную строку как текст, никакие шелл-метасимволы там не срабатывали, и этот вариант отпал сразу; xc: генерировал обычное цветное изображение без каких-либо побочных эффектов; попытки через text:, caption: и прямое чтение файлов тоже провалились. В итоге уязвимым оказался не какой-то экзотический протокол, а сама ссылка на изображение, встроенная внутрь SVG-файла, — именно она в итоге доходила до делегата и запускала произвольную команду.
По классу это ровно та же история, что случилась в 2016 году под названием ImageTragick — тогда была зафиксирована уязвимость CVE-2016-3714, тоже связанная с командной инъекцией через делегатный механизм. Автор разбора замечает, что этот класс багов «продолжает всплывать снова и снова, потому что никто не считает конвертер изображений частью поверхности атаки».
Базовый принцип для любого воркера, обрабатывающего недоверенные файлы, звучит просто: он никогда не должен обращаться к shell, никогда не должен работать с правами SYSTEM и никогда не должен иметь исходящего доступа в интернет. Конвейер Bing нарушал все три правила одновременно. Сама документация ImageMagick честно предупреждает: политика по умолчанию открыта намеренно, она рассчитана на изолированное или защищённое файрволом окружение, а не на публичные веб-сервисы, куда любой может загрузить файл.
Из рекомендаций по устранению подобных проблем наиболее эффективным считается полный запрет делегатов в policy.xml через строку вроде <policy domain="delegate" rights="none" pattern="" />. Дальше по значимости идёт сокращение списка принимаемых форматов — SVG, MVG и EPS особо отмечены как рискованные, поскольку несут в себе ссылки или встроенные интерпретаторы. Стоит также проверить delegates.xml и отключить всё, что не используется по необходимости, запускать конвертацию в песочнице с урезанными правами, заблокировать исходящий сетевой трафик с воркера (именно это звено превратило слепую SSRF в доказуемый рабочий эксплойт), настроить allowlist для адресов, к которым сервер может обращаться сам, не пуская его при этом во внутреннюю сеть, и после любого изменения политики проверять её реальное состояние командой magick identify -list policy.
Главный вывод из этой истории простой: если контент от атакующего доходит до пути с включённым делегатом в конвейере, совместимом с ImageMagick, — это и есть настоящая брешь, независимо от того, пришёл файл через форму загрузки или через серверный запрос по URL. Слепая SSRF выглядела тупиком, потому что клиенту ничего не возвращалось, но парсер за ней тихо выполнял команды с правами куда выше, чем кто-либо предполагал.
Обнаружили баг тихо, отчёт ушёл в Microsoft напрямую, без публичной огласки. CISO компании XBOW Нико Уайсман, который и написал итоговый разбор, сформулировал суть проблемы одной фразой: «Приложения относятся к обработчикам изображений как к сантехнике. Атакующие относятся к ним как к парсерам». Microsoft исправила обе уязвимости на своей стороне ещё до публикации официальных сообщений — 19 марта появились соответствующие advisory, и в тот момент ни эксплуатация, ни публичное раскрытие информации нигде не фиксировались. Полное описание механики эксплойта XBOW выпустила только 23 июля — задержка была сделана по просьбе Microsoft, чтобы дать время на устранение проблемы. Издание The Hacker News проверило статус записей CVE 24 июля: там всё ещё значилось «нет публичного раскрытия» и «не эксплуатировалось» со стороны Microsoft. Пользователям Bing делать ничего не нужно — исправление полностью серверное, никаких патчей на стороне клиента не предполагается.
Уязвимостей оказалось две, и обе получили максимальную оценку критичности — 9.8 по шкале CVSS. Первая, CVE-2026-32194, классифицируется как командная инъекция (CWE-77) и эксплуатируется через публичную функцию «Поиск по изображению»: атакующий кодирует SVG-файл в base64 и отправляет его в поле imageBin по адресу /images/kblob. Вторая, CVE-2026-32191 — это инъекция ОС-команд (CWE-78) через краулерный маршрут: злоумышленник просто размещает SVG где угодно в сети и передаёт ссылку на него через параметр imgurl, а бот bingbot/2.0 сам скачивает файл и прогоняет его через тот же уязвимый конвейер обработки. Важная деталь — ни одна из двух дыр не требовала ни аутентификации, ни куки, ни сессии, ни какого-либо клика пользователя.
С технической точки зрения обратный поиск по изображению в Bing по сути является слепой SSRF-атакой: сервер сам обращается по указанному URL за картинкой, и никакие данные напрямую клиенту не возвращаются. Зацепка обнаружилась случайно — некоторые воркеры отдавали браузеру HTTP 500, но при этом продолжали загружать и обрабатывать изображение на своей стороне. Это и стало сигналом, что где-то за фасадом ошибки происходит реальная работа с файлом. Корень проблемы оказался классическим: пакеты конвертации изображений, совместимые с ImageMagick, передают неподдерживаемые форматы во внешнюю программу-делегат, вызываемую через shell. Делегатный слой оставался включённым, и ссылка на изображение, начинающаяся с символа вертикальной черты «|», уходила не как имя файла, а прямиком в командную оболочку. Полезная нагрузка представляла собой SVG размером в один пиксель со встроенной ссылкой, которая запускала команду на воркере и через curl отправляла результат на сервер, контролируемый XBOW.
Подтверждение эксплуатации получили классическим для offensive security образом — через внеполосные (out-of-band) данные. Линуксовые воркеры вернули uid=0 и gid=0, то есть полный root. На Windows команда systeminfo показала Windows Server 2022 Datacenter, а whoami /all выдал включённые привилегии SeImpersonatePrivilege и SeDebugPrivilege — набор прав, который открывает прямую дорогу к повышению привилегий до уровня системы. Листинг директорий подтвердил, что выполнение происходило именно внутри мультимедийных компонентов обработки изображений Bing. В XBOW подчёркивают, что использовали только безобидные команды для чтения информации и не трогали данные клиентов.
Путь к финальному эксплойту занял десятки проверок. Исследователи тестировали разные псевдопротоколы ImageMagick: label: просто рендерил переданную строку как текст, никакие шелл-метасимволы там не срабатывали, и этот вариант отпал сразу; xc: генерировал обычное цветное изображение без каких-либо побочных эффектов; попытки через text:, caption: и прямое чтение файлов тоже провалились. В итоге уязвимым оказался не какой-то экзотический протокол, а сама ссылка на изображение, встроенная внутрь SVG-файла, — именно она в итоге доходила до делегата и запускала произвольную команду.
По классу это ровно та же история, что случилась в 2016 году под названием ImageTragick — тогда была зафиксирована уязвимость CVE-2016-3714, тоже связанная с командной инъекцией через делегатный механизм. Автор разбора замечает, что этот класс багов «продолжает всплывать снова и снова, потому что никто не считает конвертер изображений частью поверхности атаки».
Базовый принцип для любого воркера, обрабатывающего недоверенные файлы, звучит просто: он никогда не должен обращаться к shell, никогда не должен работать с правами SYSTEM и никогда не должен иметь исходящего доступа в интернет. Конвейер Bing нарушал все три правила одновременно. Сама документация ImageMagick честно предупреждает: политика по умолчанию открыта намеренно, она рассчитана на изолированное или защищённое файрволом окружение, а не на публичные веб-сервисы, куда любой может загрузить файл.
Из рекомендаций по устранению подобных проблем наиболее эффективным считается полный запрет делегатов в policy.xml через строку вроде <policy domain="delegate" rights="none" pattern="" />. Дальше по значимости идёт сокращение списка принимаемых форматов — SVG, MVG и EPS особо отмечены как рискованные, поскольку несут в себе ссылки или встроенные интерпретаторы. Стоит также проверить delegates.xml и отключить всё, что не используется по необходимости, запускать конвертацию в песочнице с урезанными правами, заблокировать исходящий сетевой трафик с воркера (именно это звено превратило слепую SSRF в доказуемый рабочий эксплойт), настроить allowlist для адресов, к которым сервер может обращаться сам, не пуская его при этом во внутреннюю сеть, и после любого изменения политики проверять её реальное состояние командой magick identify -list policy.
Главный вывод из этой истории простой: если контент от атакующего доходит до пути с включённым делегатом в конвейере, совместимом с ImageMagick, — это и есть настоящая брешь, независимо от того, пришёл файл через форму загрузки или через серверный запрос по URL. Слепая SSRF выглядела тупиком, потому что клиенту ничего не возвращалось, но парсер за ней тихо выполнял команды с правами куда выше, чем кто-либо предполагал.