CVE-2025-59733: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in decodeheader. The buffer td->uncompresseddata is allocated in decodeblock based on the xsize, ysize and computed currentchanneloffset.
The function dwauncompress then assumes at [5] that if there are 4 channels, these are "B", "G", "R" and "A", and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.
If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXRHALF type, then the addition at [7] will increment the pointer by 4-bytes xsize nbchannels, which will exceed the allocated buffer.
We recommend upgrading to version 8.0 or beyond.
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2025-59733?
CVE-2025-59733 has been assigned a severity rating reflecting potential security risks related to parsing malformed OpenEXR files.
How do I fix CVE-2025-59733?
To fix CVE-2025-59733, ensure that you are using the latest version of FFmpeg with patched code for handling OpenEXR files.
Which versions of FFmpeg are affected by CVE-2025-59733?
CVE-2025-59733 affects all versions of FFmpeg up to the current release as it pertains to specific image channel assumptions in OpenEXR processing.
What types of attacks can exploit CVE-2025-59733?
CVE-2025-59733 can be exploited through crafted OpenEXR files that may lead to unexpected behavior or crashes in applications using vulnerable FFmpeg versions.
Are there any workarounds for CVE-2025-59733?
As of now, the recommended workaround for CVE-2025-59733 is to avoid processing untrusted OpenEXR files until a security patch is applied.