Do you run image uploads or a web crawler through ImageMagick? Then the Bing Images RCE flaws that XBOW disclosed this week are worth more than a skim. Microsoft’s own workers ran attacker commands as SYSTEM. The cause was a default ImageMagick setting, and a lot of self-hosted pipelines still carry it. Here is exactly how the exploit worked, and what to check on your own stack.
The setting behind the bug
ImageMagick cleans up and converts images using “delegates”. These are helper programs it hands certain file types off to. Delegates are turned on by default in most installs. They let ImageMagick call out to Ghostscript for PostScript files. Other tools handle formats it cannot read on its own.
The two Bing flaws both hit that delegate path. CVE-2026-32194 came in via the public “Search by Image” upload. CVE-2026-32191 came in via Bing’s own crawler fetching a hosted file. Neither needed a login, a cookie or any user interaction. Getting a crafted file in front of the conversion code was enough.
The exploit, step by step
XBOW’s proof of concept was three lines long. It was an SVG file, one pixel in size. The file referenced an external image using an xlink:href attribute that started with a pipe character. ImageMagick’s delegate handling passed that reference straight to a shell instead of validating it as a filename. Whatever came after the pipe executed as a command.
The team’s payload ran a command and curled the result to a server they controlled. On Linux hosts the callback showed uid=0. On the Windows Server 2022 Datacenter machines running Bing’s production image pipeline, it came back as NT AUTHORITY\SYSTEM with admin group access. That is full control of the host. It came from a single image upload.
This is the same bug class as ImageTragick (CVE-2016-3714), the ImageMagick vulnerability chain from 2016. A decade on, the same delegate mechanism is still unrestricted by policy in plenty of deployments. It still turns image parsing into remote code execution whenever untrusted files reach it.
Auditing for the Bing Images RCE flaws on your own stack
Microsoft has already fixed Bing’s servers. There is nothing for Bing users to patch. But if your own service converts or thumbnails user-supplied images, run through this list. It matters more than it might seem. File upload endpoints have already been added to CISA’s Known Exploited Vulnerabilities catalog this year for far simpler bugs than the Bing Images RCE flaws.
- Lock down policy.xml. ImageMagick reads a policy file that can disable specific coders and delegates. Deny SVG, MVG and EPS unless your service genuinely needs them. Disable any delegate that shells out.
- Check delegates.xml for pipe-invoking commands. Any delegate definition that pipes a filename into a shell command is a candidate for this exact bug.
- Sandbox the conversion step. Run image processing in a low-privilege container or process with no access to the rest of your infrastructure. That way a compromised converter cannot pivot. The same priority order that applies to hardening a Linux server applies here too: least privilege first.
- Block outbound network access from the workers that do conversion. XBOW’s proof of concept relied on curling data out. A worker that cannot reach the internet cannot exfiltrate through this path.
- Treat both upload and fetch paths as untrusted. Bing’s second flaw arrived through its own crawler, not a user upload form. Any code path that fetches and processes a remote file needs the same scrutiny as a direct upload.
Why upload filters and WAFs will not save you
It is worth spelling out why standard defences miss the Bing Images RCE flaws. A file-type filter checks the extension or the declared MIME type. It will wave through a file named image.svg, because it really is an SVG. A web app firewall inspects the HTTP request too, and it won’t see anything odd either. The bad content sits inside the image’s own XML, not in headers or query parameters. The weak step comes later. That is when the conversion library reads the file’s guts and hands a value to a delegate command. Testing has to cover that step directly, not just the request that delivers the file.
Here is a simple way to check your own stack. Build a one-pixel SVG. Give it an xlink:href value that starts with a pipe character. Point it at a harmless command, one that writes a marker file or pings a host you control. Run it through your conversion pipeline in a test environment. Does the marker appear, or does the ping land? If so, your delegates are open and reachable from untrusted input. That is the exact hole XBOW used on Bing.
The broader point
XBOW’s CISO, Nico Waisman, summed up why this kept happening: “Applications treat image helpers as plumbing. Attackers treat them as parsers.” Teams tend to review authentication and input validation on the obvious entry points. The conversion library behind them gets treated as a solved problem. It rarely is. Has your organisation ever audited its image-processing dependencies for delegate behaviour? If not, this disclosure is a reasonable prompt to do it now. Better that than waiting for your own version of the Bing Images RCE flaws.
