CVE-2025-59731 in FFmpeg
Summary
by MITRE • 10/06/2025
When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.
We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_data of size rle_raw_size at [1], and then at [2] we will access entries in this buffer up to (td->xsize - 1) * (td->ysize - 1) + rle_raw_size / 2, which may exceed rle_raw_size.
We recommend upgrading to version 8.0 or beyond.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 06/21/2026
The vulnerability described in CVE-2025-59731 represents a critical buffer over-read condition within OpenEXR file processing software, specifically when handling DWAA or DWAB compressed image files. This issue manifests during the decompression and decoding process of run-length-encoded data, where the system fails to validate the raw length parameter before utilizing it in memory calculations. The flaw occurs in the sequence where the raw size is read from the input file, decompressed into a buffer of predetermined size, and subsequently accessed beyond its allocated boundaries during output data calculation.
The technical implementation of this vulnerability stems from inadequate input validation and memory management practices within the OpenEXR library's decompression routines. When processing compressed OpenEXR files, the system reads rle_raw_size from the file header at position [0] and allocates a buffer td->rle_raw_data of exactly rle_raw_size bytes at [1]. However, during the subsequent processing phase at [2], the code attempts to access memory locations calculated as (td->xsize - 1) * (td->ysize - 1) + rle_raw_size / 2, which can exceed the originally allocated buffer size. This calculation effectively bypasses the bounds checking that should prevent accessing memory beyond the allocated buffer boundaries, creating a potential exploitation vector for remote code execution or denial of service attacks.
The operational impact of this vulnerability extends beyond simple memory corruption, as it can lead to system instability, application crashes, or potentially allow attackers to execute arbitrary code within the context of the vulnerable application. The vulnerability affects any system processing OpenEXR files with DWAA or DWAB compression, making it particularly dangerous in environments where such files are frequently processed, including digital asset management systems, content creation pipelines, and image processing applications. The risk is amplified by the fact that these compression formats are commonly used in professional digital imaging workflows where automated processing is prevalent, increasing the attack surface and potential for exploitation.
This vulnerability maps to CWE-129, which specifically addresses insufficient input validation, and aligns with ATT&CK technique T1203, which involves exploitation of input validation flaws. The weakness exists in the decompression logic where the system assumes that the raw size parameter from the input file accurately represents the required buffer size without performing proper validation checks. The recommended mitigation strategy of upgrading to version 8.0 or beyond addresses the root cause by implementing proper bounds checking and input validation mechanisms that prevent the calculation from exceeding the allocated buffer boundaries, thereby eliminating the potential for memory over-read conditions.
The broader implications of this vulnerability highlight the importance of robust input validation in multimedia processing libraries, where malformed or maliciously crafted files can trigger memory corruption vulnerabilities. Security practitioners should implement comprehensive monitoring of systems processing OpenEXR files and ensure that all affected applications are updated to versions that include proper bounds checking mechanisms. Additionally, organizations should consider implementing file format validation and sandboxing techniques to limit the potential impact of such vulnerabilities in production environments where OpenEXR files may be processed from untrusted sources.