TL;DR
- what: XBOW submitted a crafted SVG to Bing image search that reached an ImageMagick delegate and executed OS commands on Microsoft's production image-processing workers.
- impact: Unauthenticated attackers got code execution as NT AUTHORITY\SYSTEM on Windows Server 2022 workers and root on Linux across multiple hosts in Bing's image tier, with no auth, cookie, session, or click required.
- fix: Microsoft remediated both CVE-2026-32194 and CVE-2026-32191 (CVSS 9.8) server-side before the March 19 advisories; there is no customer action for Bing users.
- who: Anyone running ImageMagick or ImageMagick-compatible converters on attacker-reachable uploads or server-fetched URLs with delegates enabled is exposed to the same bug class.
A crafted SVG submitted to Bing's image search ran commands as NT AUTHORITY\SYSTEM on Microsoft's production image-processing workers, and as root on the Linux machines in the same fleet. XBOW, an autonomous offensive-security startup, got the same result across different hosts and network ranges, which placed the flaw in Bing's image tier rather than on one bad machine. Microsoft issued two critical CVEs, CVE-2026-32194 and CVE-2026-32191, both rated 9.8 on CVSS. Neither requires authentication, cookies, session state, or a click.
Microsoft fixed both server-side before the advisories went up on March 19, and the records state there is no customer action to resolve. XBOW reported privately and held the exploit mechanics until remediation landed, publishing them on July 23. Bing users have nothing to patch. What outlives the fix is the shape of the bug, and that shape is sitting in a lot of other stacks.
A blind SSRF that wasn't blind
Bing's reverse image search fetches an image URL from the backend, because that is what the feature does. On its own that is a blind SSRF: nothing comes back to the client. The tell was the error handling. Some workers returned a 500 to the browser and still fetched and parsed what they retrieved, which pointed at something downstream doing the parsing. SVG answered what. It is XML, not pixels, so it can reference other images, and a renderer that follows those references goes and gets them.
Underneath, conversion suites hand formats they do not process natively to a delegate, an external program invoked through a shell. On the path XBOW reached, that layer was still enabled, so an image reference beginning with a pipe character went to the shell rather than being read as a filename. The payload was a one-pixel SVG whose reference ran a command on the worker and curled the output back to a collector XBOW controlled. The frontend could return an error while the worker executed anyway, so the proof had to come out of band.
Two routes, two CVEs
Both flaws land in the same conversion tier through different front doors. CVE-2026-32194 (command injection, CWE-77) is the public Search by Image upload, with the SVG going in base64 as the imageBin field to /images/kblob. CVE-2026-32191 (OS command injection, CWE-78) is the crawler route: host the SVG anywhere, hand its URL to the search through the imgurl parameter, and bingbot/2.0 fetches it into the same pipeline.
- Linux workers returned uid=0 and gid=0 (root).
- On Windows, systeminfo named Windows Server 2022 Datacenter; whoami /all showed SeImpersonatePrivilege and SeDebugPrivilege enabled.
- Directory listings put execution inside Bing's multimedia image-processing components.
- XBOW says it ran only benign read-only commands and touched no customer data.
Narrowing it to the delegate
Getting to that path took dozens of probes. ImageMagick pseudo-protocols behaved differently by coder: label: rendered text and xc: produced a color image, while text:, caption:, and direct file reads failed. Shell metacharacters inside label: rendered as text rather than executing, which ruled that coder out. The path that actually reached a delegate was the image reference inside the SVG itself. As XBOW CISO Nico Waisman put it: applications treat image helpers as plumbing, attackers treat them as parsers.
⚠️ If your stack pipes uploads through ImageMagick, check now — Exposure turns on whether attacker-controlled content can still reach a delegate-enabled path. If you accept file uploads or fetch server-side URLs and pass them to ImageMagick or anything ImageMagick-compatible, assume you are in scope until you have confirmed delegates are denied. This is the same class as ImageTragick (CVE-2016-3714) from 2016, and it keeps resurfacing because nobody counts the converter as attack surface.
Turn the delegates off
An image-processing worker handling untrusted files should not reach a shell, run as SYSTEM, or have a route to the internet. Bing's pipeline did all three. ImageMagick's own guidance is explicit that the default policy is open and meant for sandboxed or firewalled use, not a public website. For anything touching untrusted images, deny delegates outright in policy.xml with a policy domain="delegate" rights="none" pattern="*" entry.
- Cut the formats you accept. SVG, MVG, and EPS carry references and interpreters; disable what you do not need in delegates.xml.
- Run conversion sandboxed and with reduced privileges, never as SYSTEM or root.
- Block outbound network from the worker. That leg is what turned a blind bug into a proven one.
- Allowlist the destinations a server-side fetch may reach, and keep the worker off internal addresses.
- Test after any change: magick identify -list policy prints what is actually loaded.
The takeaway
Nothing in the HTTP response told the attacker the parser behind the fetch was exploitable. The fetch was reachable, returned nothing, and looked like a dead end, and the parser behind it turned that into a SYSTEM shell. If you outsource image handling to a converter, that converter is part of your attack surface whether you audit it or not. Deny the delegates, cut the formats, sandbox the worker, and cut its network, and the same SVG does nothing.
Originally published on RedEye Threat Intelligence.
Top comments (0)