CVE-2025-64182: 
Python vulnerability analysis and mitigation

CVE-2025-64182 is a buffer overflow vulnerability in the legacy OpenEXR Python adapter (PyOpenEXR_old) affecting the deprecated OpenEXR.InputFile wrapper. It was discovered by MegaManSec via ZeroPath and published on November 8–10, 2025. Affected versions include OpenEXR 3.2.0–3.2.4, 3.3.0–3.3.5, and 3.4.0–3.4.2 (pip package). The vulnerability carries a CVSS v3.1 base score of 7.8 (High) and a CVSS v4.0 score of 5.5 (Medium/Moderate) (GitHub Advisory, Github Advisory).

The root cause is a classic buffer overflow (CWE-120) in InputFile.channel() and InputFile.channels() within PyOpenEXR_old.cpp. In channel(), width and height are derived from the EXR header's dataWindow as int values, while typeSize is a size_t; the buffer size is computed as typeSize * width * height with no overflow or bounds checks, and the result is passed to PyBytes_FromStringAndSize(). The return value of this allocation is never checked: on 64-bit systems, if the allocation fails and returns NULL, the code immediately dereferences it causing a crash; on 32-bit systems, integer multiplication can wrap to a small positive value, producing an undersized allocation into which readPixels() then writes full scanline data, causing a heap overflow. The channels() function exhibits the same pattern and additionally ignores per-channel subsampling, hardcoding xSampling=1, ySampling=1, which can cause stride/allocation inconsistencies leading to further over- or under-writes (GitHub Advisory, Source Code).

Successful exploitation can cause application crashes (NULL dereference on 64-bit systems) or heap overflow (on 32-bit systems), with the potential for arbitrary code execution in the context of the Python process opening the malicious EXR file. Confidentiality, integrity, and availability of the affected application are all at high risk per the CVSS v3.1 assessment. The vulnerability is limited to applications using the deprecated OpenEXR.InputFile Python wrapper and requires user interaction (opening an attacker-controlled EXR file or passing crafted Python objects), constraining the attack surface to local or file-delivery scenarios (GitHub Advisory, Github Advisory).

A proof-of-concept (PoC) exploit script (write_big_header_then_crash.py) is publicly available in the GitHub security advisory, demonstrating a reliable crash on affected systems by crafting an EXR file with an oversized dataWindow header. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.016%–0.023%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Github Advisory).

1. Craft a malicious EXR file: Using the public PoC, create an EXR file with an extremely large dataWindow (e.g., width of 400,000,000 pixels) and a minimal height, using no compression. This causes the buffer size calculation typeSize * width * height to overflow or produce an allocation that is too small.
2. Deliver the file to the target: Social-engineer or otherwise cause a user or automated pipeline running a Python application that uses the deprecated OpenEXR.InputFile wrapper to open the crafted .exr file.
3. Trigger the vulnerable code path: The target application calls f.channels(["R"]) or f.channel("R") on the opened InputFile object, invoking the vulnerable channels() or channel() function in PyOpenEXR_old.cpp.
4. Achieve crash or heap overflow: On 64-bit systems, PyBytes_FromStringAndSize() returns NULL due to the oversized allocation request; the unchecked dereference causes an immediate crash (denial of service). On 32-bit systems, the integer overflow wraps to a small allocation size, and subsequent readPixels() writes beyond the buffer boundary, potentially enabling code execution (GitHub Advisory).

• Process: Python process crashes with Abort trap: 6 or similar signal (SIGABRT) when processing an EXR file; stack traces referencing PyOpenEXR_old.cpp, channel(), or channels() functions.
• Logs: Application logs showing libc++abi: terminating due to uncaught exception of type Iex_3_4::InputExc: Unable to query scanline information immediately before a crash.
• File System: Presence of unusually large .exr files (header-only, with extreme dataWindow dimensions such as width ≥ 400,000,000) in directories processed by Python image pipelines.
• Network: Unexpected delivery of .exr files from untrusted external sources to systems running OpenEXR Python bindings (GitHub Advisory).

Upgrade the OpenEXR pip package to one of the patched versions: 3.2.5, 3.3.6, or 3.4.3, which contain fixes for the integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels(). As a workaround, organizations should avoid using the deprecated OpenEXR.InputFile wrapper and migrate to the current OpenEXR Python API. Additionally, restrict EXR file processing to trusted sources and validate/sanitize input files before processing. Nessus plugin 274728 and Qualys detection ID 5010481 can be used to identify vulnerable installations (GitHub Advisory, Github Advisory).

The vulnerability was reported by security researcher MegaManSec and discovered using the ZeroPath automated security tool, as credited in the official advisory. Red Hat has acknowledged the vulnerability and published a security advisory. The issue has been picked up by Linux distribution security trackers including openSUSE (Tumbleweed November update) and Fedora (mingw-openexr updates). Splunk also issued an advisory (SVD-2026-0309) referencing this CVE. Community reaction has been limited given the moderate severity and narrow attack surface (deprecated API only) (GitHub Advisory, Red Hat Advisory).