CVE-2026-34238: Heap Buffer Overflow in ImageMagick Despeckle Operation

ImageMagick is a widely deployed open-source software suite responsible for parsing, manipulating, and converting digital images. The suite exposes a broad attack surface due to the complexity of image format specifications and algorithmic manipulations. Vulnerability CVE-2026-34238 affects the despeckle operation in ImageMagick versions prior to 7.1.2-19 and 6.9.13-44.

The vulnerability is fundamentally an integer overflow (CWE-190) that directly leads to an out-of-bounds write (CWE-787) on the heap. Specifically, the flaw exists within the DespeckleImage function, which calculates the required buffer size based on user-supplied image dimensions.

When processed on 32-bit architectures, the arithmetic operation used to determine memory allocation size can wrap around. This results in an undersized heap allocation. Subsequent pixel processing loops use the original, non-wrapped dimension values, causing uncontrolled memory corruption during pixel manipulation.

The root cause of CVE-2026-34238 resides in MagickCore/effect.c. The DespeckleImage function relies on the image->columns and image->rows attributes, which represent the width and height of the target image. To apply the despeckle filter, the algorithm requires a padded buffer, adding 2 to both dimensions before multiplying them to determine the total pixel count.

On 32-bit systems, the variable designated to store this total size is a 32-bit size_t. The maximum representable value is 4,294,967,295. The calculation executes (image->columns + 2) * (image->rows + 2). If an attacker constructs an image where both dimensions approach 65,534, the multiplication results in 4,294,967,296.

Because the result exceeds the 32-bit limit, the integer wraps around to a value near zero. The AcquireVirtualMemory function receives this undersized length argument and successfully allocates a correspondingly small heap buffer. The despeckle algorithm then iterates over the full original dimensions, writing pixel data far past the boundaries of the allocated heap chunk.

Analyzing the vulnerable implementation highlights the lack of pre-condition bounds checking before the arithmetic operation. The original code unconditionally performs the addition and multiplication in a single statement, directly casting to size_t.

/* Vulnerable MagickCore/effect.c */
MagickExport Image *DespeckleImage(const Image *image, ExceptionInfo *exception)
{
  /* ... */
  /* Allocate image buffer. Vulnerability occurs here. */
  length = (size_t)((image->columns + 2) * (image->rows + 2));
  pixel_info = AcquireVirtualMemory(length, sizeof(*pixels));
  /* ... */
}

The upstream patch (commit bcd8519c70ecd9ebbc180920f2cf97b267d1f440) introduces a boundary check for the + 2 operation, comparing the raw columns and rows against MAGICK_SIZE_MAX - 2.

/* Patched MagickCore/effect.c */
if ((image->columns > (MAGICK_SIZE_MAX-2)) ||
    (image->rows > (MAGICK_SIZE_MAX-2)))
  {
    despeckle_image=DestroyImage(despeckle_image);
    ThrowImageException(ResourceLimitError,"MemoryAllocationFailed");
  }
length=(image->columns+2)*(image->rows+2);

This patch only prevents the addition from overflowing. It does not validate the result of the multiplication. On a 32-bit target, supplying dimensions of 65,534 passes the MAGICK_SIZE_MAX - 2 check. The subsequent multiplication (65534 + 2) * (65534 + 2) still results in an overflow. This indicates the fix is incomplete, and variant attacks remain mathematically viable.

Exploitation requires the attacker to supply a maliciously crafted image to an application utilizing a vulnerable, 32-bit compiled version of ImageMagick. The attacker embeds specific structural dimensions within the image header to manipulate the columns and rows values parsed by the library.

When the application triggers the DespeckleImage function, the integer overflow occurs. This trigger often happens via explicit command-line flags (-despeckle) or automated backend image processing pipelines that apply noise-reduction algorithms. The application allocates the undersized heap chunk.

As the memory corruption triggers an out-of-bounds write of pixel data, the attacker overwrites adjacent heap metadata or application data structures. The precise exploitation sequence depends on the underlying heap allocator and the exact layout of memory at the time of the crash. AddressSanitizer logs from the initial disclosure explicitly confirm an 8-byte out-of-bounds write during this phase.

The immediate impact of triggering CVE-2026-34238 is a denial-of-service (DoS) condition. As the out-of-bounds write corrupts critical heap metadata, the application process will eventually fault and terminate. This results in high availability impact (A:H) per the CVSS v3.1 vector.

While the CVSS scoring designates confidentiality and integrity impact as none (C:N, I:N), controlled heap buffer overflows inherently introduce the risk of arbitrary code execution. An attacker capable of grooming the heap to place a target function pointer or object adjacent to the undersized allocation could hijack control flow.

Exploiting this condition for code execution requires precise memory alignment and bypassed exploit mitigations (ASLR, DEP). The complexity is marked as high (AC:H) specifically due to the strict 32-bit architectural requirement and the intricacies of heap layout grooming via an image processing pipeline.

Organizations must apply the upstream patches by upgrading ImageMagick to versions 7.1.2-19 or 6.9.13-44. Development teams utilizing the Magick.NET bindings must update their NuGet package dependencies to version 14.12.0 or later to ensure the compiled libraries incorporate the patched binaries.

In environments where immediate patching is unfeasible, administrators should implement strict boundary controls via the ImageMagick policy.xml configuration file. By globally restricting the maximum allowable width and height, the parsing engine will reject structurally oversized images before the DespeckleImage function calculates memory requirements.

The recommended policy explicitly limits the width and height resources to 16KP (16,000 pixels). This upper bound is sufficiently low to prevent the integer multiplication from approaching the 32-bit maximum limit of 4,294,967,295, successfully mitigating the overflow condition prior to the vulnerable function call.