CVE-2026-25969: Local Denial of Service via Memory Leak in ImageMagick ASHLAR Coder

The vulnerability designated as CVE-2026-25969 affects the ASHLAR image coder within ImageMagick and downstream wrappers such as Magick.NET. The ASHLAR coder is a component responsible for packing multiple individual images into a single larger canvas, a process commonly known as tiling or generating contact sheets.

This specific flaw is classified as CWE-401: Missing Release of Memory after Effective Lifetime. The vulnerability manifests during the processing of image sequences where specific height constraints are not met by the input files.

When the system evaluates an image that exceeds the remaining vertical space of the current tile, the application skips the image. During this operation, the program fails to invoke the necessary memory deallocation routines for the skipped image object.

Repeated execution of this vulnerable code path results in a steady accumulation of orphaned image structures and pixel caches in the application's heap memory. This continuous memory consumption inevitably degrades system performance and leads to an Out-Of-Memory (OOM) crash, constituting a local Denial of Service (DoS).

The root cause of the memory leak resides in the tiling layout logic implemented within coders/ashlar.c. The vulnerability is specifically located in the function responsible for iterating over and packing the input images, historically referenced as PackAshlarImages or WriteASHLARImage.

During the tiling loop, the engine calculates the spatial requirements for each sequential image. It checks if the current image's height, represented by the image->rows property, exceeds the remaining vertical space of the active tile (ashlar_info[i].height-ashlar_info[i].y).

If the height constraint is violated, the code executes a continue statement to bypass the current iteration and evaluate the next image or tile. In vulnerable versions, the code path leading to this continue statement lacks an explicit call to free the memory associated with the rejected image struct.

Consequently, the pointer reference to the image is lost when the loop advances, but the memory allocation persists on the heap. This same logical omission exists within related exception-handling blocks, where early termination of the processing loop also fails to clean up the allocated image memory.

An examination of the vulnerable source code reveals the direct mechanism of the memory leak. The logic verifies the dimensional constraints but abandons the object immediately upon failure.

// Vulnerable implementation
if (image->rows > (ashlar_info[i].height-ashlar_info[i].y))
{
  continue; // Memory leak: image pointer is lost, memory is not freed
}

The remediation introduced in commit a253d1b124ebdcc2832daac6f9a35c362635b40e implements explicit memory management prior to advancing the loop. The patch introduces a call to the DestroyImage() function.

// Patched implementation
if (image->rows > (ashlar_info[i].height-ashlar_info[i].y))
{
  images[j]=DestroyImage(image); // Fix: Explicitly release image memory
  continue;
}

The DestroyImage() function correctly deallocates the image structure, including its associated properties and pixel cache, returning a null or safe pointer. Reassigning images[j] ensures no dangling pointers remain in the application state, successfully resolving the CWE-401 vulnerability.

Exploiting this vulnerability requires an attacker to interact with an application that processes user-supplied images using the ASHLAR coder. The attack vector is localized, meaning the attacker must upload or provide the files to the targeted process.

The attacker crafts a payload consisting of a sequence of images. These images are engineered with specific vertical dimensions calculated to exceed the standard remaining space of the ASHLAR tiles configured by the target application.

When the application initiates the tiling operation, the ASHLAR coder processes the sequence. Each crafted image triggers the height constraint failure, executing the flawed continue statement and leaking the associated memory.

By repeatedly submitting these requests or submitting a single request with an exceptionally large batch of crafted images, the attacker forces the application to exhaust available system memory. This results in process termination and a denial of service.

The CVSS v3.1 base score for this vulnerability is 3.3 (Low). The vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L reflects the specific constraints required for successful exploitation.

The vulnerability is classified as Local (AV:L) and requires User Interaction (UI:R), as the system must actively process the malicious files supplied by the user. There is no impact on Confidentiality or Integrity, restricting the scope strictly to Availability (A:L).

Despite the low theoretical score, the practical impact on production systems processing user-generated content can be substantial. Applications batch-processing images without strict memory limits or process isolation will suffer service degradation or complete crashes.

Organizations utilizing Magick.NET for automated image processing pipelines, web applications generating contact sheets, or document management systems are directly exposed to this denial-of-service vector.

The primary remediation strategy is to update the affected libraries to their patched versions. Magick.NET users must upgrade to version 14.11.1 or higher across all package variants.

Applications directly integrating the C/C++ ImageMagick library must ensure the underlying version is updated to at least 7.1.2-15. Compiling from source requires incorporating commit a253d1b124ebdcc2832daac6f9a35c362635b40e.

If immediate patching is not feasible, administrators can implement workarounds by restricting the usage of the ASHLAR coder. Disabling the tiling functionality for untrusted inputs eliminates the attack surface.

Additionally, developers can implement pre-processing dimension validation. By explicitly rejecting images that exceed predefined height limits before passing them to the Magick.NET tiling engine, the vulnerable code path is never triggered.