The vulnerability CVE-2025-64183 affects the openexr library, a widely used open-source implementation of the EXR image format standard, primarily utilized in the motion picture and visual effects industries. The flaw is a use-after-free condition located in the legacy Python adapter code (pyOpenEXR_old.cpp), specifically in the function PyObject_StealAttrString. This function attempts to obtain a Python object attribute by calling PyObject_GetAttrString, which returns a new reference. However, PyObject_StealAttrString immediately decrements the reference count, resulting in a dangling pointer being returned. Subsequent calls using this pointer, such as PyLong_AsLong or PyFloat_AsDouble, operate on freed memory, causing undefined behavior. This issue manifests when reading certain EXR file attributes like PixelType.v, Box2i, and V2f. The vulnerability spans multiple versions of openexr (3.2.0-3.2.4, 3.3.0-3.3.5, and 3.4.0-3.4.2) and is resolved in later patch releases (3.2.5, 3.3.6, 3.4.3). The CVSS 4.0 vector indicates a local attack vector (AV:L), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), and high impact on availability (VA:H), with no impact on confidentiality or integrity. While no exploits are currently known in the wild, the vulnerability could cause application crashes or denial of service in software that processes EXR files via the vulnerable Python bindings. The issue is particularly relevant for organizations relying on openexr in automated pipelines or custom tooling that integrates Python bindings for image processing. Given the specialized nature of the library, exploitation requires local access and the ability to supply crafted EXR files or manipulate workflows that parse EXR data using the vulnerable code path.

For European organizations, especially those in the media, film production, and visual effects sectors, this vulnerability poses a risk of service disruption due to application crashes or instability when processing EXR image files. The use-after-free can lead to denial of service conditions, potentially halting rendering pipelines or automated image processing tasks. While the vulnerability does not directly expose sensitive data or enable remote code execution, the availability impact can cause significant operational delays and financial losses in time-sensitive production environments. Organizations using Python bindings for openexr in custom tools or workflows are at higher risk. The local attack vector means that attackers or malicious insiders must have access to the affected systems and the ability to supply or manipulate EXR files. This limits the threat surface but does not eliminate risk, especially in collaborative environments where files are exchanged frequently. The lack of known exploits reduces immediate urgency but patching is critical to prevent future exploitation and maintain operational integrity.

European organizations should immediately upgrade openexr to versions 3.2.5, 3.3.6, or 3.4.3 or later, depending on their current version branch. It is essential to audit all Python-based tools and pipelines that utilize openexr bindings to ensure they do not rely on the legacy adapter (pyOpenEXR_old.cpp) or to confirm that patched versions are in use. Where upgrading is not immediately feasible, organizations should implement strict file validation and sandboxing of EXR file processing to limit the impact of malformed files. Monitoring for abnormal crashes or memory errors in image processing applications can help detect exploitation attempts. Additionally, restricting local access to systems handling EXR files and enforcing strict user permissions can reduce the risk of malicious file injection. Development teams should review custom scripts or integrations that parse EXR attributes to avoid unsafe use of Python C API functions on potentially freed objects. Finally, maintain awareness of updates from the AcademySoftwareFoundation and apply security patches promptly.