ImageMagick use-after-free: critical vulnerability in FormatMagickCaption (CVE-2026-61861)

A new ImageMagick use-after-free vulnerability (CVE-2026-61861) has once again exposed the dangers of automated image processing on servers. The vulnerability is located in the FormatMagickCaption and could lead to a denial of service or remote code execution if an attacker manages to trigger a memory allocation failure during processing.

ImageMagick is one of the most widely used image conversion and processing libraries in the world, integrated into countless web applications, content management systems, and CI/CD pipelines. Every time a user uploads an image to a forum, blog, e-shop, or SaaS platform, chances are high that an ImageMagick binary is running somewhere in the background — and that's exactly what makes such vulnerabilities particularly dangerous.

What exactly does ImageMagick use-after-free do?

The vulnerability, CVE-2026-61861, occurs in the FormatMagickCaption method , a function responsible for formatting caption text on images. The problem starts when an internal memory allocation fails: instead of cleanly breaking the execution flow, the code continues and accesses a pointer that has already been freed. This is the classic use-after-free (UAF) pattern , one of the most dangerous classes of errors in memory security.

The dangling pointer can, under certain circumstances, be reused by the attacker to control what is read or written to that memory location. In its mildest form, the server crashes (denial of service). In its most severe form, the attacker manages to achieve remote code execution with the privileges of the process running ImageMagick — usually the web server or worker container.

The trick behind the attack: exhausting memory

The discovery that makes ImageMagick use-after-free unique is the way it is triggered. The attacker does not need to discover a complex sequence of bytes — all they need to do is force the process to fail a memory allocation. This can be achieved by uploading a specially crafted caption image with huge parameters (large fonts, extended text, unusual dimensions), while filling the server heap with other requests.

When the next call to malloc returns NULL , the FormatMagickCaption logic doesn't handle the failure case correctly — and that's where the UAF state kicks in. Memory-exhaustion attacks on server-side image processing libraries are becoming increasingly popular, as they allow bypassing input checks that focus solely on the file format.

What attack surface is exposed?

ImageMagick use-after-free affects significantly more installations than one might think. Typical examples of exposed systems:

• WordPress installations that use ImageMagick instead of GD for thumbnails.
• Content delivery pipelines that create custom banners with text.
• SaaS watermarking and photo editing applications.
• Serverless functions (AWS Lambda, Cloud Run) that handle uploads.
• Older Linux distributions (Debian, Ubuntu, RHEL) where package updates are delayed.

Of particular concern is the fact that many administrators don't even realize they're running ImageMagick on their infrastructure — and thus don't realize that ImageMagick use-after-free directly affects them. The library is often integrated as a dependency in PHP GD alternatives, as a backend for PIL/Pillow in Python, or as a command-line tool via wrappers in Ruby, Node.js, and Go.

ImageMagick vulnerability history — ImageMagick use-after-free is not unique

ImageMagick has a long history of serious security bugs. In 2016, the infamous ImageTragick allowed command injection via specially crafted SVGs. In 2022, a series of heap overflows in PNG/TIFF parsers led to emergency patches. In 2025, a PoC exploit was released for an RCE vulnerability in ImageMagick that exploited a buffer overflow in a format handler.

The pattern repeats itself: a library written in C, with a huge attack surface (over 200 supported image formats), runs with server privileges and accepts untrusted input directly from the internet. Each new parser added brings new potential avenues for exploitation, while the legacy codebase struggles to incorporate modern memory safety techniques.

How to protect yourself from ImageMagick use-after-free

The SecNews technical team recommends immediate mitigation steps that all administrators should implement without delay:

• Upgrade to ImageMagick 7.1.2-26 or later, where UAF has been fixed.
• For Debian/Ubuntu: update imagemagick package via apt when the backport reaches the security channel.
• For containers: rebuild the base images with the patched version and re-deploy.
• Enabling policy.xml with strict memory, disk and format whitelisting restrictions.
• Isolation of worker processes that handle user uploads in separate containers with minimal privileges.
• Setting strict rate limits on image upload endpoints to prevent memory-exhaustion attacks.

For CI/CD pipelines and serverless functions, it is a good idea to add checking with scanning tools like trivy or grype to the build process, so that new vulnerabilities in libraries like ImageMagick are detected before they reach production.

The biggest lesson from ImageMagick use-after-free

The constant stream of vulnerabilities in old C libraries reminds us that choosing the right tooling comes at a serious security cost. Many modern alternatives — from libvips to Sharp and VIPS — offer better memory safety and protection against UAFs and heap overflows. For new implementations, the SecNews editorial team recommends evaluating alternatives before continuing to use ImageMagick.

See also: PoC Exploit released for RCE vulnerability in ImageMagick

See also: Vulnerability in Progress OpenEdge allows code execution

See also: Windows 11: Old Microsoft patch created new vulnerability