Infinite Loops & Infinite Sadness: The MSL Ouroboros in ImageMagick (CVE-2026-23874)

ImageMagick is the 'duct tape' of the internet. It is the software library responsible for resizing your profile picture on forums, converting your PDFs to JPEGs, and generally handling image manipulation on millions of servers worldwide. Because it tries to support every file format known to humanity—from the mundane PNG to the esoteric SUN Rasterfile—it has a massive attack surface. Complexity is the enemy of security, and ImageMagick is very complex.

One of the darker corners of ImageMagick is the Magick Scripting Language (MSL). Did you know ImageMagick has its own XML-based scripting language? Neither did most sysadmins. It allows you to define image processing pipelines in an XML file rather than chaining command-line arguments. While powerful, it introduces the classic vulnerability vector: a parser that executes logic defined by untrusted input.

CVE-2026-23874 is a reminder that obscure features are often the most fragile. It’s a stack overflow vulnerability caused by a logic flaw in how MSL handles file writing. It’s not a memory corruption bug in the traditional buffer overflow sense—no heap spraying required here. Instead, it’s a logic bomb that forces the application to eat its own tail until it explodes.

The vulnerability resides in coders/msl.c, specifically in how the MSL parser handles the <write> tag. In a normal workflow, an MSL script reads an image, performs some operations (resize, crop, blur), and then writes the result to a file.

Here is the logic flaw: ImageMagick treats file formats as abstractions. If you write to output.jpg, it calls the JPEG encoder. If you write to output.png, it calls the PNG encoder. But what happens if you write to output.msl?

When the <write> tag specifies the msl: protocol or an .msl extension, ImageMagick invokes the MSL writer. However, because MSL is a scripting language, 'writing' to it isn't just dumping bytes; in the context of this specific coder, the implementation inadvertently triggers the parsing logic again to handle the structure. This creates a recursive loop: The Parser encounters <write> -> Calls WriteImage -> Selects MSL Coder -> MSL Coder invokes processing -> Parser starts again.

Without a depth limit or a check to prevent the MSL coder from being invoked recursively during a write operation, the function calls pile up on the stack. Eventually, the stack pointer hits the guard page, the OS screams, and the process terminates with a segmentation fault. It's a classic Denial of Service via resource exhaustion.

Let's look at the smoking gun in coders/msl.c. The vulnerability was patched in commit 2a09644b10a5b146e0a7c63b778bd74a112ebec3. Below is the critical logic inside MSLStartElement, the function responsible for parsing XML tags in the script.

Before the Fix:

/* Vulnerable Logic */
if (LocaleCompare((char *) tag,"write") == 0)
{
  // ... setup image info ...
  (void) WriteImage(msl_info->image_info[n], 
                    msl_info->image[n], 
                    msl_info->exception);
  break;
}

The code simply blindly calls WriteImage with whatever filename and format the user provided in the XML attributes. If the user provided msl:, WriteImage re-enters the MSL machinery.

After the Fix:

/* Patched Logic */
(void) CopyMagickString(msl_info->image_info[n]->filename,
  msl_info->image[n]->filename,MagickPathExtent);
(void) SetImageInfo(msl_info->image_info[n],1,exception);
 
/* The Check */
if (LocaleCompare(msl_info->image_info[n]->magick,"msl") != 0)
  {
    *msl_info->image_info[n]->magick='\0';
    (void) WriteImage(msl_info->image_info[n],msl_info->image[n],
      msl_info->exception);
  }
else
  (void) ThrowMagickException(msl_info->exception,GetMagickModule(),
    FileOpenError,"UnableToWriteFile","`%s'",
    msl_info->image[n]->filename);

The fix is a hard stop. The developers added a check using LocaleCompare to see if the resolved magic format is "msl". If it is, they throw a FileOpenError exception immediately, preventing the recursive call to WriteImage. It's a crude but effective patch: "Doctor, it hurts when I do this." "Then don't do that."

Exploiting this is trivially easy if you can feed an MSL file to ImageMagick. This might happen in web applications that allow users to upload 'image' files but fail to validate the file header, passing everything to magick convert.

Here is a Proof-of-Concept (PoC) crash.msl:

<?xml version="1.0" encoding="UTF-8"?>
<image>
  <read filename="logo:" />
  <write filename="msl:recursion.msl" />
</image>

The Execution Flow:

1. Loader: You run magick crash.msl.
2. Read: ImageMagick reads the built-in logo: image into memory.
3. Write: The parser hits the <write> tag. The filename starts with msl:, forcing the MSL coder.
4. Recursion: The MSL coder attempts to process the output operation, re-invoking the MSL parsing context.
5. Loop: Steps 3 and 4 repeat instantly.
6. Crash: The stack exhausts, and the application segfaults.

While this is primarily a Denial of Service (DoS), never underestimate the chaos a reliable crash can cause. In a serverless environment (like AWS Lambda), this might just cost the attacker money. In a persistent server environment, repeatedly crashing the image processor can fill logs, exhaust thread pools if the crash isn't handled cleanly, or destabilize the entire service.

In the grand scheme of things, a CVSS 5.5 (Local DoS) isn't going to make the evening news. However, for a service provider hosting an image conversion API, this is a nuisance. If your architecture relies on ImageMagick processing files from untrusted users, this bug allows any user to kill the worker process handling their request.

If the worker process is not isolated (e.g., it's a thread in a larger application rather than a spawned process), this vulnerability brings down the whole application. The attack complexity is low, and no special privileges are needed beyond the ability to submit a file.

Furthermore, this highlights the danger of 'Polyglot' inputs. An attacker might hide this XML payload inside a valid-looking image file or change the extension to .jpg hoping the detection logic relies solely on file extensions, while ImageMagick's magic-byte detection might still decide to treat it as MSL text.

If you are running ImageMagick, you have two options. The first and best option is to upgrade. Version 7.1.2-13 includes the patch that explicitly forbids writing to MSL formats from within an MSL script.

If you cannot upgrade immediately (perhaps you are dependent on a specific legacy version for other reasons), you can use ImageMagick's robust policy.xml framework to neuter the attack vector. The policy.xml file allows administrators to disable specific coders.

Mitigation via Policy:

Add the following line to your policy.xml (usually found in /etc/ImageMagick-7/):

<policy domain="coder" rights="none" pattern="MSL" />

This policy completely disables the MSL coder. Unless your application specifically requires the ability to execute MSL scripts (which is rare for standard web apps), this is a safe and highly recommended hardening step regardless of this specific CVE. It closes the door not just on this bug, but on any future bugs found in the MSL interpreter.