CVE-2026-40310: Heap-Based Out-of-Bounds Write in ImageMagick JP2 Encoder

ImageMagick is an open-source software suite utilized for displaying, converting, and editing raster and vector image files. Within its extensive library of codecs, the JPEG 2000 (JP2) encoder processes images formatted according to the JP2 standard. CVE-2026-40310 identifies a heap-based out-of-bounds write vulnerability within this specific encoder component. The vulnerability is classified under CWE-122 (Heap-based Buffer Overflow) and CWE-787 (Out-of-bounds Write).

The vulnerability manifests when the encoder parses a user-supplied sampling index possessing a value of zero. Sampling factors in the JPEG 2000 format dictate the downsampling ratio applied to individual color components during the encoding phase. When the application receives a zero value, downstream mathematical operations compute an incorrectly minimal buffer size. This undersized allocation creates the primary condition for a subsequent memory corruption event when the full image data stream is written into the buffer.

Successful exploitation results in a denial of service due to an application crash triggered by a memory access violation. While heap corruption vulnerabilities possess the theoretical capability for arbitrary code execution, no weaponized exploit currently exists for this specific path. The vulnerability impacts the ImageMagick 7.x branch prior to version 7.1.2-19 and the 6.x branch prior to version 6.9.13-44. Downstream wrapper libraries, such as Magick.NET, are inherently affected prior to version 14.12.0.

The root cause of CVE-2026-40310 is the absence of boundary validation for user-supplied mathematical parameters within the WriteJP2Image function. This function, located in the coders/jp2.c file, handles the translation of internal ImageMagick pixel structures into the final JP2 file format. During initialization, the function parses the sampling-factor attribute to determine the horizontal and vertical subsampling requirements. The logic extracts these values directly from the geometry_info.rho and geometry_info.sigma variables populated by the configuration parser.

Prior to the patch, the application assigned these extracted values to parameters->subsampling_dx and parameters->subsampling_dy without verifying they were positive, non-zero integers. In the context of spatial downsampling, a factor of zero is mathematically undefined within the JPEG 2000 specification. The standard requires the subsampling factors to represent a strictly positive ratio for dimensional reduction. By omitting this validation step, the encoder permitted a zero multiplier to propagate deeply into the memory allocation logic.

When the zero factor reaches the buffer allocation routines, it invalidates the calculation of the required component data size. The memory allocator receives a request for a buffer significantly smaller than the actual uncompressed image data requires. Once the minimally sized buffer is allocated on the heap by the underlying standard library, the encoder proceeds to write the spatial image stream into this constrained space. The write loop executes for the full duration of the image dimensions, continuing past the allocated boundary, corrupting adjacent heap chunks, and triggering the out-of-bounds write.

An examination of the unpatched coders/jp2.c reveals the direct assignment of user-controlled variables. The ParseGeometry function evaluates the sampling_factor string from the user-provided image information structure and populates the geometry_info object. The application then uses a bitwise check against RhoValue and SigmaValue to determine if horizontal and vertical factors were specified. If present, the values are cast to integers and immediately stored in the parameter structure without sanity checks.

/* coders/jp2.c - Vulnerable Logic */
flags=ParseGeometry(image_info->sampling_factor,&geometry_info);
if ((flags & RhoValue) != 0)
  parameters->subsampling_dx=(int) geometry_info.rho;
parameters->subsampling_dy=parameters->subsampling_dx;
if ((flags & SigmaValue) != 0)
  parameters->subsampling_dy=(int) geometry_info.sigma;

The fix addresses this logical omission by introducing the MagickMax macro during the parameter assignment phase. The macro compares the user-supplied geometry value against a hardcoded float value of 1.0. The larger of the two values is then safely cast to an integer and assigned to the parameter fields. This ensures that any value less than one, including zero or negative numbers, is overridden.

/* coders/jp2.c - Patched Logic */
flags=ParseGeometry(image_info->sampling_factor,&geometry_info);
if ((flags & RhoValue) != 0)
  parameters->subsampling_dx=(int) MagickMax(
    geometry_info.rho,1.0);
parameters->subsampling_dy=parameters->subsampling_dx;
if ((flags & SigmaValue) != 0)
  parameters->subsampling_dy=(int) MagickMax(
    geometry_info.sigma,1.0);

This implementation successfully eliminates the vulnerability by guaranteeing that the subsampling parameters maintain a strict minimum value of 1. The subsequent memory allocation calculations rely on these guaranteed minimums, ensuring they always request a buffer size consistent with the geometric requirements of the target image stream. The fix comprehensively secures this specific code path and introduces no operational regressions.

Exploitation of CVE-2026-40310 relies strictly on a local or client-side attack vector and mandates direct user interaction. An attacker must construct a malformed image file or direct the application to process a benign image utilizing a crafted configuration payload. The vulnerability requires the target application to process the file utilizing the affected JP2 encoder. The complexity of triggering the vulnerability is categorized as low, as the attacker merely needs to specify the value 0 within the sampling-factor attribute.

In a standard exploitation scenario, an adversary provides the malicious input through command-line arguments or via a web application that blindly passes user uploads directly to the ImageMagick binary. For example, supplying the argument -sampling-factor 0x0 alongside an input image file forces the ParseGeometry function to extract zeroes for both the horizontal and vertical geometry axes. Alternatively, if the target application parses embedded metadata profiles that allow parameter injection, the attacker can embed the zero-value geometry directly into the file to trigger the flaw upon processing.

Current exploit maturity for this specific vulnerability remains at the proof-of-concept level. Public demonstrations are strictly focused on triggering the out-of-bounds write to cause an application crash. No weaponized exploit payloads designed to achieve remote code execution are documented in public repositories. Elevating this heap corruption from a denial-of-service condition to arbitrary code execution requires highly precise control over the heap layout to overwrite adjacent function pointers, a task significantly complicated by modern operating system exploit mitigations.

The immediate operational consequence of successfully triggering CVE-2026-40310 is a severe disruption of application availability. When the out-of-bounds write process corrupts heap metadata or contiguous memory regions, the operating system's memory manager detects the corruption and forces the process to terminate via a segmentation fault. For automated image processing pipelines, background worker instances handling user avatars, or document conversion services, this denial-of-service condition causes the processing thread to abruptly fail.

While the CVSS vector restricts the calculated impact strictly to availability (A:H), heap-based buffer overflows possess inherent risks regarding system compromise. If an attacker systematically controls the exact size of the initial allocation and the specific contents of the written image data, they might selectively overwrite adjacent functional objects on the heap. Overwriting these data structures could theoretically allow an attacker to alter the execution flow, though the technical barrier for reliable code execution via the JP2 codepath remains substantial.

The vulnerability is assigned a CVSS v3.1 base score of 5.5, accurately reflecting its local attack vector and reliance on user interaction. The Exploit Prediction Scoring System (EPSS) assigns a probability score of 0.00012, placing the vulnerability in the 1.52 percentile. These quantitative metrics indicate that the likelihood of widespread, automated exploitation in the wild is exceedingly low. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

The definitive remediation for CVE-2026-40310 requires upgrading the ImageMagick software suite to a fully patched release. System administrators must deploy ImageMagick version 7.1.2-19 or 6.9.13-44, which integrate the required bounds checking in the WriteJP2Image allocation logic. Operators should verify their deployed installation version utilizing the magick -version command and consult their operating system's respective package manager for the latest distribution packages. Applications statically linking the ImageMagick C libraries require a complete recompilation against the patched source tree.

Software ecosystems utilizing wrapper libraries around the ImageMagick API remain vulnerable until explicitly updated. Developers integrating the Magick.NET library within C# or F# environments must upgrade their project dependency to version 14.12.0 or greater. This specific update ensures the underlying unmanaged binaries correctly enforce the strict minimum value constraints on all subsampling factors. Failing to update the wrapper library leaves the dependent .NET application fully susceptible to the heap corruption via malformed user uploads.

In operational environments where immediate binary patching is unfeasible, administrators can implement input validation logic as a temporary mitigation layer. Applications accepting image processing parameters directly from end users must explicitly sanitize the sampling-factor string, discarding any configurations containing the integer zero or non-numeric input. Furthermore, security personnel can implement constraints via the ImageMagick policy.xml file to explicitly deny the processing of JP2 formatted files if the application does not require JPEG 2000 support.