CVE-2026-59204: Denial of Service via Memory Exhaustion in Pillow JPEG2000 Decoder

The Pillow imaging library includes native C implementations for processing specialized image formats, including the JPEG2000 standard. The JPEG2000 decoder relies on the open-source OpenJPEG library to handle the compressed codestream, passing decoded pixels to a Pillow-specific memory buffer for structural reorganization. Within this subsystem, a security flaw was discovered in the tiled decompressor logic that permits unauthenticated remote attackers to trigger resource exhaustion.

The vulnerability is classified under CWE-789 (Memory Allocation with Excessive Size Value) and CWE-770 (Allocation of Resources Without Limits or Throttling). It exists because the decoder retains and accumulates state variables across independent decoding operations. Consequently, processing multi-tiled JPEG2000 images leads to exponential memory overhead relative to the dimensions of the file.

This technical analysis details the memory-management flaw within Pillow's decoding routine, walks through the C code patch, and outlines defensive mechanisms to prevent process crash attacks. The flaw affects Pillow versions from 8.2.0 through 12.2.0 and has been resolved in version 12.3.0.

To understand the mechanics of the vulnerability, it is necessary to examine how the JPEG2000 standard utilizes image tiling. Tiling divides an image into discrete, independent rectangular segments that can be decoded sequentially, minimizing the overall memory requirements for systems processing large images. Pillow handles this logic within the j2k_decode_entry function inside the src/libImaging/Jpeg2KDecode.c source file.

During the decoding sequence, the function loops through each individual tile, extracting metadata and allocating a transient scratch buffer to store the raw decompressed pixel bytes. To size this scratch buffer, the engine calculates the required byte allocation using the dimensions of the active tile and the width of its cumulative component channels. This width tracking is managed by the integer variable total_component_width.

In vulnerable versions, the decoder initializes total_component_width to zero outside the loop that iterates over each image tile. As the decoder moves from one tile to the next, it fails to reset this variable. Instead, the decoder continually adds the component widths of subsequent tiles to the running total.

When the decoder invokes realloc on the state scratch buffer to accommodate the newly computed dimensions, the memory requirement balloons far beyond the system's actual capacity. For images configured with hundreds or thousands of tiny tiles, this accumulation behavior rapidly scales the allocation request into gigabytes. The operating system encounters an Out-of-Memory (OOM) condition and terminates the parent Python process, resulting in a denial of service.

The vulnerability resides in src/libImaging/Jpeg2KDecode.c. Below is an annotated visual comparison of the vulnerable decoding structure versus the remediated code path.

/* VULNERABLE CODE - src/libImaging/Jpeg2KDecode.c */
j2k_decode_entry(Imaging im, ImagingCodecState state) {
    size_t tile_bytes = 0;
    unsigned n, tile_height, tile_width;
    int total_component_width = 0; // Vulnerability: Declared outside the loop scope
 
    stream = opj_stream_create(BUFFER_SIZE, OPJ_TRUE);
 
    // Loop iterating over each tile in the JPEG2000 codestream
    for (/* tile loop */) {
        // total_component_width is NOT reset to 0 here
 
        for (n = 0; n < tile_info.nb_comps; n++) {
            int csize = (image->comps[n].prec + 7) >> 3;
            // Accumulation bug: Adds to the value from previous iterations
            total_component_width += csize * image->comps[n].w;
        }
 
        // Formula generates progressively larger sizes
        tile_bytes = total_component_width * tile_height * tile_width;
 
        // Allocation size exceeds physical memory bounds
        state->buffer = realloc(state->buffer, tile_bytes);
    }
}

The patch merged in Git commit 13ada41172142f2fd9f0906f615a00ea623a11ca resolves this state accumulation by shifting the declaration of total_component_width to local scope within the loop.

/* PATCHED CODE - src/libImaging/Jpeg2KDecode.c */
j2k_decode_entry(Imaging im, ImagingCodecState state) {
    size_t tile_bytes = 0;
    unsigned n, tile_height, tile_width;
    // total_component_width removed from this outer scope
 
    stream = opj_stream_create(BUFFER_SIZE, OPJ_TRUE);
 
    for (/* tile loop */) {
        // Fix: re-initialized to 0 on every loop iteration
        int total_component_width = 0;
 
        for (n = 0; n < tile_info.nb_comps; n++) {
            int csize = (image->comps[n].prec + 7) >> 3;
            // Accumulation is restricted to the components of the current tile
            total_component_width += csize * image->comps[n].w;
        }
 
        // Calculation accurately reflects only the active tile
        tile_bytes = total_component_width * tile_height * tile_width;
 
        // realloc scales within correct boundaries
        state->buffer = realloc(state->buffer, tile_bytes);
    }
}

While this patch effectively isolates tile calculations, security engineers must note that state->buffer is resized upward via realloc() but is never resized downward. If an image begins with an extremely large tile followed by numerous small tiles, the peak memory allocation remains allocated on the heap for the duration of the decoding cycle. This behavior can still create a high resident memory footprint under specific conditions.

Exploiting CVE-2026-59204 requires no specific privileges and can be executed remotely if the target application processes user-supplied images. The attacker must supply a JPEG2000 file crafted with a dense grid of tiles. Because standard defensive controls in web applications typically inspect total image dimensions rather than tile density, the payload file easily bypasses standard image-resolution filters.

The attacker constructs a JPEG2000 image codestream containing a high count of small tiles (for example, a 2000x2000 pixel image divided into 10x10 pixel tiles, yielding 40,000 distinct tiles). The payload is transmitted via an image upload or manipulation endpoint. When the backend service loads the image data, Pillow's format sniffer recognizes the JPEG2000 magic bytes and routes the data stream to the decoding logic.

As the decoder processes the 40,000 tiles sequentially, the variable total_component_width increases during every iteration. By the time the loop reaches intermediate iterations, the calculated value of tile_bytes requests several gigabytes of memory. Because the system cannot satisfy this sudden request for contiguous memory, the runtime environment throws an out-of-memory error, causing the operating system to immediately terminate the worker process.

The impact of CVE-2026-59204 is restricted to application-level Denial of Service (DoS). Because the vulnerability results in process termination due to unhandled out-of-memory conditions, there is no direct risk of remote code execution or unauthorized information disclosure. However, in modern microservice architectures, a persistent crash of image processing nodes can degrade overall service availability.

The Common Vulnerability Scoring System (CVSS) v3.1 assigns a Base Score of 7.5 (High) to this flaw, reflecting network-based exploitability with low complexity and zero privilege requirements. Under CVSS v4.0, the severity is rated at 8.7 (High), emphasizing the total loss of availability for the parsing service.

The Exploit Prediction Scoring System (EPSS) maintains a low immediate probability of active exploitation in wild campaigns. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there are no public weaponized exploits available.

Organizations running vulnerable Pillow instances should upgrade to version 12.3.0 or later to patch the underlying C source files. When immediate library upgrades are not feasible, security administrators can implement input filtering at the application boundary to reject JPEG2000 images before they reach the decoding subsystem.

The most effective application-level workaround is to restrict the permitted image formats during the invocation of Image.open(). By explicitly specifying an allowed format list, the Pillow engine will reject JPEG2000 codestreams without attempting to parse them.

from PIL import Image
 
# Enforce an explicit format whitelist excluding JPEG2000
SAFE_FORMATS = ["PNG", "JPEG", "GIF", "WEBP"]
 
try:
    with Image.open("user_file.bin", formats=SAFE_FORMATS) as img:
        img.load()
except Exception as err:
    # Handle rejected format safely
    pass

To mitigate the system-level impact of potential memory exhaustion, deploy image-processing workers inside isolated execution environments with strict resource constraints. For example, Docker containers can be configured with memory ceilings to prevent a single parsing process from consuming host resources or affecting neighboring services. This ensures that process termination affects only the processing container and does not cause host-level cascading failures.