CVE-2025-64183: 
Python vulnerability analysis and mitigation

CVE-2025-64183 is a use-after-free (UAF) vulnerability in the legacy Python adapter of OpenEXR, specifically in the PyObject_StealAttrString function within pyOpenEXR_old.cpp. It affects OpenEXR versions 3.2.0–3.2.4, 3.3.0–3.3.5, and 3.4.0–3.4.2 (PyPI package). The vulnerability was discovered with ZeroPath and first published on November 8–10, 2025. It carries a CVSS v3.1 base score of 7.5 (High) assigned by NVD, and a CVSS v4.0 score of 5.5 (Medium) assigned by GitHub as the CNA (Github Advisory, OpenEXR Advisory).

The root cause is a use-after-free (CWE-416) in the legacy Python wrapper's PyObject_StealAttrString helper function in pyOpenEXR_old.cpp (lines 109–115). The function calls PyObject_GetAttrString to obtain a new Python object reference, immediately calls Py_DECREF on it (potentially freeing the object if the reference count drops to zero), and then returns the now-dangling pointer. Callers throughout the file then pass this freed pointer to APIs such as PyLong_AsLong and PyFloat_AsDouble when parsing EXR file attributes including PixelType.v, Box2i, and V2f fields. This pattern is repeated in multiple call sites (e.g., lines 380–387 and 1258–1286), making the vulnerability broadly triggerable whenever the legacy adapter processes EXR attribute data (OpenEXR Advisory, Source Code).

Successful exploitation of this vulnerability primarily impacts availability, causing application crashes (segmentation faults) in processes that use the OpenEXR Python bindings to parse EXR files. Depending on heap state and memory layout at the time of exploitation, the use-after-free condition could theoretically be leveraged for remote code execution, though this is context-dependent and not confirmed in practice. There is no direct confidentiality or integrity impact identified. Applications in the motion picture, VFX, and media industries that process EXR files via the legacy Python adapter are most at risk (Github Advisory, OpenEXR Advisory).

A proof-of-concept (PoC) exploit is publicly available in the official security advisory, demonstrating a reliable crash (segmentation fault) under PYTHONMALLOC=debug by passing a crafted PixelTypeProxy object to OpenEXR.InputFile.channel(). The EPSS score is approximately 0.072–0.14% (22nd percentile), indicating low near-term exploitation probability. There is no evidence of active in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (OpenEXR Advisory, Github Advisory).

1. Identify target: Locate an application or service that uses the OpenEXR Python package (pip) in versions 3.2.0–3.2.4, 3.3.0–3.3.5, or 3.4.0–3.4.2 and accepts EXR file input or exposes the legacy OpenEXR.InputFile API.
2. Prepare a crafted Python object: Create a PixelTypeProxy class whose .v property returns a fresh temporary integer subclass instance (e.g., a subclass of int with a __del__ method that allocates memory to stir the heap), ensuring the reference count drops to zero when Py_DECREF is called inside PyObject_StealAttrString.
3. Trigger the vulnerable code path: Call OpenEXR.InputFile(path).channel('R', pixel_type=PixelTypeProxy()) with any valid EXR file. The legacy adapter invokes PyObject_StealAttrString(pixel_type, 'v'), which decrefs the returned object to zero and returns a dangling pointer.
4. Achieve use-after-free: The dangling pointer is passed to PyLong_AsLong, which reads from freed memory. Under normal conditions this causes a segmentation fault (crash/DoS); under specific heap conditions, it may allow memory corruption for further exploitation.
5. Amplify impact (optional): Use AddressSanitizer or PYTHONMALLOC=debug to confirm the UAF; in a real attack scenario, heap grooming techniques could potentially be used to attempt controlled memory corruption (OpenEXR Advisory).

• Process: Unexpected segmentation faults or crashes in Python processes using the OpenEXR package, particularly in applications processing EXR files; crash dumps referencing _Z16init_OpenEXR_oldP7_object or OpenEXR.cpython-*.so.
• Logs: Python fatal error messages such as Fatal Python error: Segmentation fault in application logs, with stack traces involving PyObject_Vectorcall, method_vectorcall_VARARGS_KEYWORDS, or _PyEval_EvalFrameDefault alongside OpenEXR.cpython shared library frames.
• File System: Presence of OpenEXR Python package versions 3.2.0–3.2.4, 3.3.0–3.3.5, or 3.4.0–3.4.2 in installed pip packages (verifiable via pip show openexr).
• Network: Unexpected or malformed EXR files submitted to file upload endpoints or media processing pipelines, especially those with unusual PixelType, Box2i, or V2f attribute structures (OpenEXR Advisory).

Upgrade the OpenEXR Python package to the patched versions: 3.2.5, 3.3.6, or 3.4.3, which fix the use-after-free in PyObject_StealAttrString. Until patching is possible, restrict or disable processing of EXR files from untrusted sources, and avoid exposing the legacy OpenEXR.InputFile API to untrusted input. Additionally, validate and sanitize all EXR file inputs before processing, and monitor for application crashes related to EXR file handling (OpenEXR Advisory, Github Advisory).

The vulnerability was discovered using ZeroPath automated security tooling and credited to researcher MegaManSec. Red Hat has acknowledged the CVE and published a security advisory. OpenSUSE Tumbleweed included the fix in its November 2025 monthly update, and Fedora issued mingw-openexr updates addressing this CVE. Splunk also published an advisory (SVD-2026-0309) referencing this vulnerability. Community reaction has been limited given the moderate severity and niche scope of the affected legacy Python adapter (Red Hat Advisory, OpenEXR Advisory).