CVE-2026-25637: ImageMagick Memory Leak DoS Vulnerability

CVE-2026-25637 Overview

A memory leak vulnerability exists in ImageMagick, the widely-used open-source image editing and manipulation software. Prior to version 7.1.2-15, the ASHLAR image writer contains a flaw that allows an attacker to exhaust process memory by providing a specially crafted image. This results in small objects being allocated but never freed, potentially leading to denial of service conditions through resource exhaustion.

Critical Impact

Attackers can exploit this memory leak vulnerability to cause denial of service by exhausting process memory on systems processing untrusted images with ImageMagick.

Affected Products

• ImageMagick versions prior to 7.1.2-15
• Magick.NET versions prior to 14.10.3
• Applications and services using vulnerable ImageMagick libraries for image processing

Discovery Timeline

• 2026-02-24 - CVE-2026-25637 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-25637

Vulnerability Analysis

This vulnerability is classified as CWE-401 (Missing Release of Memory after Effective Lifetime), commonly known as a memory leak. The flaw resides in the ASHLAR image coder component (coders/ashlar.c) of ImageMagick. When processing images with specific characteristics, the code allocates DrawInfo structures that are never properly deallocated, causing memory to accumulate over time.

The vulnerability is network-exploitable, as many applications use ImageMagick to process user-uploaded images on web servers. An attacker can repeatedly submit crafted images to gradually consume all available process memory, eventually causing the application to crash or become unresponsive.

Root Cause

The root cause stems from improper resource management in the ASHLAR image writer. The CloneDrawInfo function was called unconditionally at the start of a code block, but the corresponding DestroyDrawInfo cleanup call was missing entirely. This meant that whenever the label processing logic was executed, a new DrawInfo object was allocated but never freed, regardless of whether the label was successfully processed.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Crafting a malicious image file designed to trigger the ASHLAR writer's label processing code path
2. Submitting the image to a web application or service that uses a vulnerable ImageMagick version for image processing
3. Repeating the process to gradually exhaust server memory
4. Continuing until the target service experiences denial of service due to memory exhaustion

           *label,
           offset[MagickPathExtent];
 
-        DrawInfo
-          *draw_info = CloneDrawInfo(image_info,(DrawInfo *) NULL);
-
         label=InterpretImageProperties((ImageInfo *) image_info,tile_image,
           value,exception);
         if (label != (const char *) NULL)
           {
+            DrawInfo
+              *draw_info = CloneDrawInfo(image_info,(DrawInfo *) NULL);
+
             (void) CloneString(&draw_info->text,label);
             label=DestroyString(label);
             (void) FormatLocaleString(offset,MagickPathExtent,"%+g%+g",(double)
               tiles[i].x+geometry.x,(double) tiles[i].height+tiles[i].y-
               geometry.y/2.0+4);
             (void) CloneString(&draw_info->geometry,offset);
             status=AnnotateImage(ashlar_image,draw_info,exception);
+            draw_info=DestroyDrawInfo(draw_info);
           }
       }
#if defined(MAGICKCORE_OPENMP_SUPPORT)

Source: GitHub Commit Update

The patch moves the CloneDrawInfo allocation inside the conditional block where it's actually needed and adds the missing DestroyDrawInfo call to properly free the allocated memory.

Detection Methods for CVE-2026-25637

Indicators of Compromise

• Abnormally high memory consumption by ImageMagick processes or applications using ImageMagick libraries
• Gradual memory growth without corresponding decrease during image processing operations
• Out-of-memory errors or crashes in services handling image uploads
• Unusual patterns of image upload requests targeting the affected system

Detection Strategies

• Monitor process memory utilization for ImageMagick-related processes and set alerts for abnormal growth patterns
• Implement application-level logging to track memory allocation trends during image processing operations
• Deploy SentinelOne Singularity Platform for real-time process behavioral analysis and resource anomaly detection
• Review web application logs for suspicious patterns of repeated image upload requests

Monitoring Recommendations

• Configure memory threshold alerts for processes handling image conversions
• Implement rate limiting on image upload endpoints to slow potential exploitation attempts
• Enable detailed logging for ImageMagick operations to identify problematic images
• Use SentinelOne's Vigilance MDR service for 24/7 monitoring of suspicious process behavior

How to Mitigate CVE-2026-25637

Immediate Actions Required

• Upgrade ImageMagick to version 7.1.2-15 or later immediately on all affected systems
• For Magick.NET users, upgrade to version 14.10.3 or later
• Audit all applications and services that incorporate ImageMagick for image processing
• Implement resource limits (memory cgroups, ulimits) for processes handling untrusted images

Patch Information

ImageMagick has released a security patch in version 7.1.2-15 that resolves this memory leak vulnerability. The fix ensures that DrawInfo objects are only allocated when needed and are properly deallocated after use. Users of the Magick.NET wrapper library should upgrade to version 14.10.3, which incorporates the upstream fix.

For detailed patch information, refer to the GitHub Security Advisory GHSA-gm37-qx7w-p258 and the GitHub Commit Update.

Workarounds

• Implement strict file size and dimension limits on uploaded images to reduce exploitation impact
• Configure ImageMagick resource limits using policy.xml to restrict memory allocation
• Process untrusted images in isolated containers or sandboxed environments with memory limits
• Disable the ASHLAR coder if not required by adding it to the policy.xml coder blocklist

# Example ImageMagick policy.xml configuration to limit resources
# Add to /etc/ImageMagick-7/policy.xml or equivalent

# Limit memory allocation
<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>

# Disable ASHLAR coder if not needed
<policy domain="coder" rights="none" pattern="ASHLAR"/>