CVE-2026-33900: Heap-Based Buffer Overflow via Integer Truncation in ImageMagick VIFF Encoder

ImageMagick is a widely deployed open-source software suite used for displaying, creating, converting, and editing raster image and vector image files. The software includes support for a vast array of file formats, handled by specific encoder and decoder modules. The viff module is responsible for processing Khoros Visualization Image Format (VIFF) files. This format is heavily utilized in scientific and technical computing contexts.

A vulnerability exists within the WriteVIFFImage function of the VIFF encoder when the software is compiled and executed on 32-bit architectures. The flaw is classified as an Integer Overflow or Wraparound (CWE-190) but practically functions as an integer truncation bug. The vulnerability occurs because the memory allocation mechanism improperly handles 64-bit dimension data when casting it to the native architecture's pointer width.

When a 32-bit instance of ImageMagick processes an image with extreme dimensions, the truncation during the memory allocation phase results in a buffer that is significantly smaller than required. The subsequent processing loop then writes the full 64-bit quantity of data into this undersized buffer. This out-of-bounds write operation constitutes a classical heap-based buffer overflow, enabling an attacker to corrupt adjacent heap memory chunks.

The root cause of CVE-2026-33900 is an implicit 64-bit to 32-bit integer truncation in coders/viff.c. ImageMagick uses a specialized type called MagickSizeType, which is a 64-bit unsigned integer, to track the packets variable. This variable represents the total count of pixel data units that need to be processed for the target VIFF image.

The calculation of packets correctly handles large image dimensions because it occurs within a 64-bit context. However, the system relies on the AcquireVirtualMemory function to allocate the corresponding memory buffer. The function signature of AcquireVirtualMemory accepts a size_t argument for the allocation size. On a 32-bit operating system or build environment, size_t is exactly 32 bits wide.

When packets is passed to AcquireVirtualMemory, a type cast from MagickSizeType to size_t takes place. If the value of packets exceeds the maximum value of a 32-bit unsigned integer ($2^{32}-1$), the upper 32 bits are discarded. For example, a packets value of 0x100000005 will be truncated to 0x00000005. The allocator provisions memory for only 5 units, but the subsequent memory write routines operate on the original 64-bit value, executing an extensive out-of-bounds write across the heap.

The vulnerability is localized to a specific memory allocation call within WriteVIFFImage. The unpatched code performs a direct cast without verifying if the value fits within the target architectural constraints. The vulnerable implementation invokes pixel_info=AcquireVirtualMemory((size_t) packets,sizeof(*pixels));.

The official patch, introduced in commit d27b840a61b322419a66d0d192ff56d52498148d, implements a standard integer truncation validation mechanism. The maintainers added a round-trip cast check immediately preceding the memory allocation. This approach verifies that no data is lost during the downcast to size_t.

+    if (packets != (MagickSizeType) ((size_t) packets))
+      ThrowWriterException(ResourceLimitError,"MemoryAllocationFailed");
     pixel_info=AcquireVirtualMemory((size_t) packets,sizeof(*pixels));

The patched logic casts the 64-bit packets to a 32-bit size_t, then immediately casts the result back to the 64-bit MagickSizeType. If the original value was greater than the 32-bit maximum, the truncation causes the round-trip value to differ from the original. The conditional check intercepts this disparity and safely aborts the operation by throwing a ResourceLimitError. This fix is architecturally complete and comprehensively addresses the specific memory exhaustion and truncation vectors present in the VIFF encoder.

Exploiting this vulnerability requires specific environmental preconditions and the construction of a tailored malicious file. The primary requirement is that the target application or service must be utilizing a 32-bit build of the ImageMagick or Magick.NET library. The attacker must then identify an attack surface where user-supplied images are processed, converted, or written to the VIFF format.

The payload construction phase requires the attacker to manipulate the image header dimensions (width and height) to produce a specific pixel count. The attacker calculates values such that width multiplied by height yields a packets value slightly larger than $2^{32}$. By aiming for a truncated value like 0x00000010, the attacker ensures the allocation is small, making it easier to overwrite adjacent heap structures with deterministic data.

During execution, the application allocates the undersized chunk. As the image processing loop executes, it writes the attacker-controlled pixel data into memory beyond the bounds of the allocated chunk. This corrupts adjacent heap metadata and application data. Depending on the memory layout and the underlying libc allocator (e.g., ptmalloc), this corruption typically results in a denial of service via a segmentation fault. Developing this into reliable remote code execution requires precise heap massaging to overwrite function pointers or object vtables, which is complicated by the large volume of data being written.

The CVSS v3.1 base score for CVE-2026-33900 is calculated at 5.9 (Medium severity), primarily driven by the High Availability impact and High Attack Complexity. The vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflects the network-accessible nature of the vulnerability, requiring no user interaction or specialized privileges to trigger.

The High Attack Complexity (AC:H) rating is justified by the requirement for the specific 32-bit architecture environment. Modern server deployments predominantly utilize 64-bit operating systems and binaries, significantly reducing the widespread exploitation potential. However, embedded systems, legacy software containers, and specific Windows application environments often still rely on 32-bit libraries, leaving them exposed.

The primary realized impact is denial of service. The out-of-bounds heap write inevitably triggers memory corruption protections in modern operating systems, resulting in immediate process termination. While arbitrary code execution is theoretically possible, the massive scale of the out-of-bounds write (typically exceeding 4GB of data) frequently causes the process to hit unmapped memory pages and crash before execution control can be successfully hijacked.

The absolute and definitive remediation for this vulnerability is applying the vendor-supplied patches. Organizations utilizing ImageMagick must upgrade to version 7.1.2-19 or 6.9.13-44. Development teams utilizing the Magick.NET bindings in C# or other .NET environments must upgrade the respective NuGet packages to version 14.12.0 or later. This ensures the truncation validation logic is present.

For environments where immediate patching is untenable, organizations can leverage ImageMagick's built-in policy configuration file (policy.xml) to implement mitigating controls. Administrators should explicitly restrict the maximum width, height, and memory limits for processed images. Setting rigorous boundaries on the area and memory parameters prevents the allocation function from ever processing dimension values large enough to trigger the 32-bit integer boundary overflow.

Furthermore, migrating production systems to 64-bit architectures entirely neutralizes this specific vulnerability vector. On 64-bit builds, size_t is inherently 64 bits wide, meaning the cast from MagickSizeType to size_t performs no truncation. Security engineering teams should mandate the deprecation of 32-bit media processing binaries across deployment pipelines to harden the environment against similar memory management flaws.