CVE-2025-59733
published 2025-10-06CVE-2025-59733: 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)…
PriorityP340high8.7CVSS 4.0
AVAACHATNPRNUIPVCHVIHVANSCHSIHSANEXCRXIRXARXMAVXMACXMATXMPRXMUIXMVCXMVIXMVAXMSCXMSIXMSAXSXAUXRXVXREXUX
EPSS
0.17%
6.9th percentile
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 decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress 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 EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.
We recommend upgrading to version 8.0 or beyond.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | ffmpeg | < ffmpeg 7:5.1.7-0+deb12u1 (bookworm) | ffmpeg 7:5.1.7-0+deb12u1 (bookworm) |
| ffmpeg | ffmpeg | >= 0 < 7:5.1.7-0+deb12u1 | 7:5.1.7-0+deb12u1 |
| ffmpeg | ffmpeg | >= 0 < 7:7.1.2-0+deb13u1 | 7:7.1.2-0+deb13u1 |
| ffmpeg | ffmpeg | >= 0 < 7:7.1.2-1 | 7:7.1.2-1 |
| ffmpeg | ffmpeg | >= 0 < 7:7.1.1-1ubuntu4.2 | 7:7.1.1-1ubuntu4.2 |
| ffmpeg | ffmpeg | >= 0 < 7:2.8.17-0ubuntu0.1+esm14 | 7:2.8.17-0ubuntu0.1+esm14 |
| ffmpeg | ffmpeg | >= 0 < 7:3.4.11-0ubuntu0.1+esm12 | 7:3.4.11-0ubuntu0.1+esm12 |
| ffmpeg | ffmpeg | >= 0 < 7:4.2.7-0ubuntu0.1+esm12 | 7:4.2.7-0ubuntu0.1+esm12 |
| ffmpeg | ffmpeg | >= 0 < 7:4.4.2-0ubuntu0.22.04.1+esm11 | 7:4.4.2-0ubuntu0.22.04.1+esm11 |
| ffmpeg | ffmpeg | >= 0 < 7:6.1.1-3ubuntu5+esm7 | 7:6.1.1-3ubuntu5+esm7 |
| ffmpeg | ffmpeg | >= 7.1.1 < 8.0 | 8.0 |
| ffmpeg | ffmpeg | >= 9a32b863074ed4140141e0d3613905c6f1fe61c5 < 8.0 | 8.0 |
CVSS provenance
nvdv4.08.7HIGHCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
osv8.7HIGH
vendor_debian8.7HIGH
vendor_redhat8.7HIGH
vendor_ubuntu7.5HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Ubuntu
FFmpeg vulnerabilities
vendor_ubuntu·2026-01-27·CVSS 7.5
CVE-2025-59728 [HIGH] FFmpeg vulnerabilities
Title: FFmpeg vulnerabilities
Summary: Several security issues were fixed in FFmpeg.
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to cause a denial
of service or execute arbitrary code. This issue only affected
Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 25.10.
(CVE-2025-59728)
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to cause a denial
of service or execute arbitrary code. This issue only affected
Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 25.10. (CVE-2025-59731,
CVE-2025-59732)
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to
Red Hat
FFmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding
vendor_redhat·2025-10-06·CVSS 8.7
CVE-2025-59733 [HIGH] CWE-787 FFmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding
FFmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding
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 decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress 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 unknow
Debian
CVE-2025-59733: ffmpeg - When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an imp...
vendor_debian·2025·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733: ffmpeg - When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an imp...
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 decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset. The function dwa_uncompress 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 EXR_HALF type, then the addition at [7
OSV
ffmpeg vulnerabilities
osv·2026-01-27·CVSS 8.7
CVE-2025-59728 [HIGH] ffmpeg vulnerabilities
ffmpeg vulnerabilities
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to cause a denial
of service or execute arbitrary code. This issue only affected
Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 25.10.
(CVE-2025-59728)
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to cause a denial
of service or execute arbitrary code. This issue only affected
Ubuntu 22.04 LTS, Ubuntu 24.04 LTS and Ubuntu 25.10. (CVE-2025-59731,
CVE-2025-59732)
It was discovered that FFmpeg did not correctly handle certain memory
operations. An attacker could possibly use this issue to cause a denial
of service or execute arbitrary code. This issue
GHSA
GHSA-hpfq-c235-5854: 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
ghsa_unreviewed·2025-10-06
CVE-2025-59733 [HIGH] CWE-787 GHSA-hpfq-c235-5854: 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
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 decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress 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 EXR_HALF type, then the addition at
OSV
CVE-2025-59733: 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
osv·2025-10-06·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733: 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
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 decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset. The function dwa_uncompress 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 EXR_HALF type, then the addition at [7
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2025-59733 ffmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
bugzilla·2025-11-28·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733 ffmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
CVE-2025-59733 ffmpeg: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT.
https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
Discussion:
This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug
Bugzilla
CVE-2025-59733 qt5-qtwebengine: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
bugzilla·2025-11-28·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733 qt5-qtwebengine: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
CVE-2025-59733 qt5-qtwebengine: FFmpeg: Buffer overflow in OpenEXR DWAA/DWAB decoding [fedora-42]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT.
https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
Discussion:
This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to clos
Bugzilla
CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-10]
bugzilla·2025-10-06·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-10]
CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-10]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT.
https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
Discussion:
Fixed in 7.1.2:
https://github.com/FFmpeg/FFmpeg/commit/a9ec8317498b62192cc3df95ef2523eae8ec0294
Bugzilla
CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-9]
bugzilla·2025-10-06·CVSS 8.7
CVE-2025-59733 [HIGH] CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-9]
CVE-2025-59733 ffmpeg: Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress [epel-9]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT.
https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
Discussion:
FEDORA-EPEL-2026-7e25a1d2ec (ffmpeg-5.1.9-1.el9) has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-7e25a1d2ec
---
Known as BIGSLEEP-43651175
2025-10-06
Published