CVE-2026-59183: 
Wolfi vulnerability analysis and mitigation

CVE-2026-59183 is a signed integer overflow vulnerability in OpenEXR's OpenEXRCore library that leads to an out-of-bounds memory read and application crash when decoding a crafted deep tiled EXR file. It affects OpenEXR versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, and was published on August 25, 2026. The vulnerability was discovered by researcher izumi-hyun and disclosed via GitHub Security Advisory GHSA-rqp5-pmwm-wj6x. It carries a CVSS v3.1 base score of 5.5 (Medium) (GitHub Advisory).

The root cause is a CWE-190 (Integer Overflow or Wraparound) combined with CWE-125 (Out-of-Bounds Read) in src/lib/OpenEXRCore/decoding.c. In the unpack_sample_table() function, the tile width (w) and height (h) are declared as int32_t, and the loop index computation y * w overflows to a negative value when tile dimensions are large (e.g., 46342×46342, where width * (height - 1) > INT32_MAX). This produces an invalid pointer approximately 8 GB before the allocated buffer, causing a segmentation fault (SEGV) on memory read. The overflow occurs in the standard decoding path (exr_decoding_run), meaning any application using OpenEXR to decode deep tiled EXR files is affected. The vulnerability was confirmed using AddressSanitizer (ASAN) and independently verified with UndefinedBehaviorSanitizer (UBSan) (GitHub Advisory, Fix Commit).

Successful exploitation results in a Denial of Service (DoS) — any application that decodes a crafted deep tiled EXR file will crash due to a read from an unmapped memory address. There is no confidentiality or integrity impact; the vulnerability is limited to availability. Because OpenEXR is widely used in VFX and motion picture production pipelines, affected applications include rendering tools, compositing software, and any pipeline component that processes EXR files via the OpenEXRCore library (GitHub Advisory).

No in-the-wild exploitation has been reported, and no exploit kits or weaponized code are known to exist beyond the proof-of-concept Python script included in the security advisory. Exploitation requires user interaction — a victim application must open a specially crafted deep tiled EXR file — and the system must have sufficient memory (~8.6 GB) to allocate the sample count table. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Craft a malicious EXR file: Use the Python PoC script from the advisory to generate a deep tiled EXR file with tile dimensions of 46342×46342 (NONE compression, all-zero sample counts). The resulting file is approximately 8.6 GB and is structured to trigger the integer overflow during decoding.
2. Deliver the file to a target: Social-engineer a user or automated pipeline into opening the crafted .exr file with a vulnerable application (e.g., a VFX tool, renderer, or any software using OpenEXR 3.1.0–3.4.13).
3. Trigger decoding: When the application calls exr_decoding_run on the deep tiled file, unpack_sample_table() is invoked. The int32_t multiplication y * w overflows for large tile rows, producing a negative pointer offset.
4. Crash the application: The invalid pointer causes a read from an unmapped memory address (~8 GB before the allocated buffer), resulting in a SEGV and application crash, achieving Denial of Service (GitHub Advisory).

• File System: Presence of unusually large (multi-gigabyte) .exr files with deep tiled format and extreme tile dimensions (e.g., 46342×46342); files with NONE compression and all-zero sample count tables.
• Logs: Application crash logs or core dumps referencing unpack_sample_table, exr_decoding_run, or realloc_deepdata in stack traces; ASAN/SEGV signals from EXR-processing applications.
• Process: Unexpected termination (SIGBUS/SIGSEGV) of rendering, compositing, or image-processing applications immediately after opening an EXR file (GitHub Advisory).

Upgrade to the patched versions: 3.2.11, 3.3.13, or 3.4.14, which fix the overflow by declaring w, h, and the loop variable y as int64_t instead of int32_t in unpack_sample_table(). As a workaround where upgrading is not immediately possible, configure max_image_size in OpenEXR to reject files with tile dimensions that could trigger the overflow (i.e., reject tiles where width * height > INT32_MAX). Avoid processing untrusted deep tiled EXR files with unpatched versions (GitHub Advisory, Fix Commit).