CVE-2023-34151 - New Vulnerability in ImageMagick—How Double-to-size

ImageMagick is one of the most widely used tools for processing and editing images. If you work with servers, websites, or any automated graphic workflows, you've probably interacted with ImageMagick, even if you didn't know it. But, just like any popular software, it's become a magnet for security researchers—and attackers.

In this post, I'll break down a fresh vulnerability known as CVE-2023-34151. This bug picks up where a previous issue, CVE-2022-32546, left off—it's all about dangerous type casting in ImageMagick's codebase. We'll see why this is risky, give an easy-to-understand code example, discuss how it can be abused, and where you can learn more or test it yourself.

What Is CVE-2023-34151?

In simple terms, CVE-2023-34151 is a vulnerability that was found in ImageMagick's handling of certain image formats, like SVG and MVG. The root of the problem is "undefined behavior" that occurs when the code converts a floating-point number (a double) into a different data type called size_t, which represents a size or length in memory.

If you give ImageMagick an SVG or MVG (or possibly other formats) with certain values, this buggy conversion can cause ImageMagick to allocate the wrong amount of memory, read or write out of bounds, or even crash. Sometimes, with smart exploitation, an attacker might run their own code.

And yes, this is a recurring bug. A previous security flaw, CVE-2022-32546, was supposed to fix a similar issue, but the fix didn't cover every place where this dangerous cast happens.

Why Is Double-to-size_t Casting Dangerous?

In C (the language ImageMagick is written in), converting a double (which can store huge numbers and fractions) to a size_t (which only stores whole numbers, and usually only up to a certain max size) is poorly defined if the value is out of range. What happens if the double is negative? Or gigantic? There is no guarantee.

For example

double val = -100.25;
size_t length = (size_t)val;

Here, length will not be -100 (since size_t is *unsigned* and can't be negative). Instead, the value will wrap around and become a very large positive number, or zero, depending on the platform.

If this variable is then used to read input or allocate memory, weird or dangerous things can happen.

How Does CVE-2023-34151 Happen In Practice?

The vulnerability can be triggered by crafting a malicious SVG or MVG image file with manipulated numeric attributes. When ImageMagick parses this file, it tries to handle these values, but accidentally casts them to size_t without proper checks.

A rough attack scenario

1. An attacker uploads a specially crafted SVG file to a server that uses ImageMagick to process user images.
2. The SVG contains extremely large or negative values in certain SVG parameters—those could be dimensions or transformation matrices.
3. When ImageMagick parses the SVG, it performs (size_t)some_double, producing a wildly unexpected value for buffer allocations or memory access.
4. This can crash the service, cause memory corruption, or—if the right conditions are met—let the attacker run their own code on the server.

Below is a simplified (and fictionalized) example of how this issue could show up in C code

// Imaginary snippet in ImageMagick's SVG handling code
double svg_length = get_length_from_svg(input);
size_t buf_size = (size_t)svg_length;

char *buffer = malloc(buf_size);

if (buffer == NULL) {
    // handle error
}

// Use buffer...

If svg_length is negative (say, -1.), it could convert to a huge positive value because size_t underflows.
If it’s 1e20, it could become zero, due to overflow or truncation, leading to a zero-length allocation and later overflows.

Who Is At Risk?

Any ImageMagick deployment that accepts user-controlled image uploads or remote files—especially if SVG or MVG parsers are enabled—is at risk. This is common in:

Web applications with profile pic uploads

- Messaging apps/scripts that resize or convert images

How Could This Be Exploited?

Exploitability varies based on your setup. At best, an attacker could just crash the service (denial of service). At worst, with a carefully designed image, an attacker could achieve remote code execution (RCE).

There are reports of successful exploit attempts against similar bugs by chaining heap overflows with other weaknesses (like predictable heap layout or use-after-free bugs).

Here's what a minimal malicious SVG might look like (for a buffer allocation bug)

<svg width="-100000000" height="10">
  <rect x="" y="" width="100" height="100"/>
</svg>

If you process this SVG with an unpatched ImageMagick, you could trigger a crash

convert malicious.svg out.png

ImageMagick security advisory:

https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-x9rj-8f28-3r2q

Original bug report:

https://github.com/ImageMagick/ImageMagick/issues/6215

CVE details page:

https://nvd.nist.gov/vuln/detail/CVE-2023-34151

https://nvd.nist.gov/vuln/detail/CVE-2022-32546

Always use the latest version, as the maintainers patch these bugs regularly.

Disable Unused Coders

If you don’t need SVG/MVG support, disable them at compile-time or in your policies.

Sandbox ImageMagick

Run image processing in a locked-down environment (like a Docker container, with minimal privileges).

Validate User Inputs

If you control the PNG/JPEG pipeline, reject unneeded formats before passing files to ImageMagick.

Summary

CVE-2023-34151 is another reminder that small programming mistakes, like unsafe type casting, can have big consequences—especially in software that touches user data.

If you’re running anything that uses ImageMagick, check your version, patch up, and consider how to reduce exposure. And pay attention to even "boring" bugs—sometimes, they're the door an attacker needs.

*Want to learn more about secure image processing? Follow security advisories, and keep your dependencies fresh!*

References
- ImageMagick Security Advisory on GHSA-x9rj-8f28-3r2q
- CVE-2023-34151 (National Vulnerability Database)
- Previous Related Bug: CVE-2022-32546
- ImageMagick GitHub Issue #6215

Timeline

Published on: 05/30/2023 22:15:00 UTC
Last modified on: 06/07/2023 13:57:00 UTC