Every CVE Search/ Get API key

CVE-2025-59733

Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress

8.7 HighFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Adjacent network
Complexity
High
Privileges needed
None
User interaction
Passive

What an attacker can affect

Confidentiality
High
Integrity
High
Availability
None

Exploit likelihood

0.18%Up 0.2 points since Oct 6, 2025
90%50%10%1%

What each source reports

CVE List Score used 8.7

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 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.

Record
CVE-2025-59733
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Weakness
CWE-787
Updated
2026-11-02
EUVDEUVD-2025-32183 8.7

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.

Record
EUVD-2025-32183
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-hpfq-c235-5854 8.7

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption...

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.

Record
GHSA-hpfq-c235-5854
CVSS 4.0
8.7 HighCVSS: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
Weakness
CWE-787
Updated
2026-11-02
NVD 8.7

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.

Record
CVE-2025-59733
CVSS 4.0
8.7 HighCVSS: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
Weakness
CWE-787
Updated
2026-11-02
OSVALPINE-CVE-2025-59733 8.7

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.

Record
ALPINE-CVE-2025-59733
CVSS 4.0
8.7 HighCVSS: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
Updated
2026-11-03
OSV 8.7

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 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.

Record
CVE-2025-59733
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Weakness
CWE-787
Updated
2026-11-02
Show 7 moreShow less
OSVDEBIAN-CVE-2025-59733 8.7

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.

Record
DEBIAN-CVE-2025-59733
CVSS 4.0
8.7 HighCVSS: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
Updated
2026-11-02
OSVJLSEC-2026-646 8.7

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption...

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.

Record
JLSEC-2026-646
CVSS 4.0
8.7 HighCVSS: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
Updated
2026-11-02
OSVOESA-2026-3284 8.7

ffmpeg security update

FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash.

Security Fix(es):

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.

If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.

The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.

We recommend upgrading to version 8.0 or beyond.(CVE-2025-59732)

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.(CVE-2025-59733)

A heap-buffer-overflow write exists in jpeg2000dec FFmpeg which allows an attacker to potentially gain remote code execution or cause denial of service via the channel definition cdef atom of JPEG2000.(CVE-2025-9951)

Record
OESA-2026-3284
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Updated
2026-11-02
OSVOESA-2026-3285 8.7

ffmpeg security update

FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash.

Security Fix(es):

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.

If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.

The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.

We recommend upgrading to version 8.0 or beyond.(CVE-2025-59732)

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.(CVE-2025-59733)

A heap-buffer-overflow write exists in jpeg2000dec FFmpeg which allows an attacker to potentially gain remote code execution or cause denial of service via the channel definition cdef atom of JPEG2000.(CVE-2025-9951)

Record
OESA-2026-3285
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Updated
2026-11-02
OSVOESA-2026-3286 8.7

ffmpeg security update

FFmpeg is a complete and free Internet live audio and video broadcasting solution for Linux/Unix. It also includes a digital VCR. It can encode in real time in many formats including MPEG1 audio and video, MPEG4, h263, ac3, asf, avi, real, mjpeg, and flash.

Security Fix(es):

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.

If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.

The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.

We recommend upgrading to version 8.0 or beyond.(CVE-2025-59732)

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.(CVE-2025-59733)

A heap-buffer-overflow write exists in jpeg2000dec FFmpeg which allows an attacker to potentially gain remote code execution or cause denial of service via the channel definition cdef atom of JPEG2000.(CVE-2025-9951)

Record
OESA-2026-3286
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Updated
2026-11-02
OSVUBUNTU-CVE-2025-59733 8.7

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.

Record
UBUNTU-CVE-2025-59733
CVSS 4.0
8.7 HighCVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
Updated
2026-11-02
OSVMGASA-2025-0306 No score

Updated ffmpeg packages fix security vulnerabilities

FFmpeg v.n6.1-3-g466799d4f5 allows an attacker to trigger use of a parameter of negative size in the av_samples_set_silence function in thelibavutil/samplefmt.c:260:9 component. (CVE-2023-50007) FFmpeg v.n6.1-3-g466799d4f5 allows memory consumption when using the colorcorrect filter, in the av_malloc function in libavutil/mem.c:105:9 component. (CVE-2023-50008) Improper handling of input format in tty demuxer of ffmpeg. (CVE-2023-6602) Hls xbin demuxer dos amplification in ffmpeg. (CVE-2023-6604) Dash playlist ssrf vulnerability in ffmpeg. (CVE-2023-6605) FFmpeg version n6.1 was discovered to contain a heap buffer overflow vulnerability in the draw_block_rectangle function of libavfilter/vf_codecview.c. This vulnerability allows attackers to cause undefined behavior or a Denial of Service (DoS) via crafted input. (CVE-2024-31582) FFmpeg n6.1.1 has an Out-of-bounds Read via libavcodec/ppc/vp8dsp_altivec.c, static const vec_s8 h_subpel_filters_outer. (CVE-2024-35367) Heap-buffer-overflow write in FFmpeg MDASH resolve_content_path. (CVE-2025-59728) Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress. (CVE-2025-59731, CVE-2025-59732, CVE-2025-59733) Null pointer dereference in ffmpeg als decoder (libavcodec/alsdec.c). (CVE-2025-7700)

Record
MGASA-2025-0306
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
ffmpeg
Alpine:v3.23
before 8.0-r0
8.0-r0
ffmpeg
Alpine:v3.24
before 8.0-r0
8.0-r0
ffmpeg
Debian:12
before 7:5.1.7-0+deb12u1, plus listed versions
7:5.1.3-17:5.1.3-27:5.1.4-0+deb12u17:5.1.5-0+deb12u17:5.1.6-0+deb12u1
7:5.1.7-0+deb12u1
ffmpeg
Debian:13
before 7:7.1.2-0+deb13u1, plus listed versions
7:7.1.1-1
7:7.1.2-0+deb13u1
ffmpeg
Debian:14
before 7:7.1.2-1, plus listed versions
7:7.1.1-1
7:7.1.2-1
ffmpeg
Debian:12
From an advisory covering 16 CVEs
before 7:5.1.7-0+deb12u1, plus listed versions
7:5.1.3-17:5.1.3-27:5.1.4-0+deb12u17:5.1.5-0+deb12u17:5.1.6-0+deb12u1
7:5.1.7-0+deb12u1
ffmpeg
Debian:13
From an advisory covering 8 CVEs
before 7:7.1.2-0+deb13u1, plus listed versions
7:7.1.1-1
7:7.1.2-0+deb13u1
FFMPEG_jll
Julia
7.1.1+0 up to 8.0.0+0
8.0.0+0
FFplay_jll
Julia
7.1.1+0 up to 8.1.2+0
8.1.2+0
ffmpeg
Mageia:9
From an advisory covering 12 CVEs
before 5.1.7-1.mga9
5.1.7-1.mga9
Show 10 moreShow less
Affected packages
PackageAffectedFixed
ffmpeg
Mageia:9
From an advisory covering 12 CVEs
before 5.1.7-1.mga9.tainted
5.1.7-1.mga9.tainted
ffmpeg
openEuler:24.03-LTS-SP1
From an advisory covering 3 CVEs
before 6.1.1-40.oe2403sp1
6.1.1-40.oe2403sp1
ffmpeg
openEuler:24.03-LTS-SP3
From an advisory covering 3 CVEs
before 6.1.1-40.oe2403sp3
6.1.1-40.oe2403sp3
ffmpeg
openEuler:24.03-LTS-SP4
From an advisory covering 3 CVEs
before 6.1.1-40.oe2403sp4
6.1.1-40.oe2403sp4
libav
Ubuntu:Pro:14.04:LTS
All versions, plus listed versions
6:0.8.7-1ubuntu26:9.10-1ubuntu16:9.10-1ubuntu26:9.10-1ubuntu56:9.10-1ubuntu6
Show 9 moreShow less
6:9.10-1ubuntu76:9.11-2ubuntu16:9.11-2ubuntu26:9.13-0ubuntu0.14.04.16:9.14-0ubuntu0.14.04.16:9.16-0ubuntu0.14.04.16:9.18-0ubuntu0.14.04.16:9.20-0ubuntu0.14.04.16:9.20-0ubuntu0.14.04.1+esm1
None known
ffmpeg
Ubuntu:Pro:18.04:LTS
before 7:3.4.11-0ubuntu0.1+esm12, plus listed versions
7:3.3.4-27:3.3.4-2build37:3.4-2ubuntu27:3.4-47:3.4-4build1
Show 20 moreShow less
7:3.4.1-17:3.4.1-1build17:3.4.2-17:3.4.2-1build17:3.4.2-27:3.4.4-0ubuntu0.18.04.17:3.4.6-0ubuntu0.18.04.17:3.4.8-0ubuntu0.27:3.4.11-0ubuntu0.17:3.4.11-0ubuntu0.1+esm17:3.4.11-0ubuntu0.1+esm27:3.4.11-0ubuntu0.1+esm37:3.4.11-0ubuntu0.1+esm47:3.4.11-0ubuntu0.1+esm57:3.4.11-0ubuntu0.1+esm67:3.4.11-0ubuntu0.1+esm77:3.4.11-0ubuntu0.1+esm87:3.4.11-0ubuntu0.1+esm97:3.4.11-0ubuntu0.1+esm107:3.4.11-0ubuntu0.1+esm11
7:3.4.11-0ubuntu0.1+esm12
ffmpeg
Ubuntu:Pro:20.04:LTS
before 7:4.2.7-0ubuntu0.1+esm12, plus listed versions
7:4.1.4-1build27:4.2.1-27:4.2.1-2ubuntu17:4.2.2-1build17:4.2.2-1ubuntu1
Show 14 moreShow less
7:4.2.4-1ubuntu0.17:4.2.4-1ubuntu0.1+esm17:4.2.7-0ubuntu0.17:4.2.7-0ubuntu0.1+esm17:4.2.7-0ubuntu0.1+esm27:4.2.7-0ubuntu0.1+esm37:4.2.7-0ubuntu0.1+esm47:4.2.7-0ubuntu0.1+esm57:4.2.7-0ubuntu0.1+esm67:4.2.7-0ubuntu0.1+esm77:4.2.7-0ubuntu0.1+esm87:4.2.7-0ubuntu0.1+esm97:4.2.7-0ubuntu0.1+esm107:4.2.7-0ubuntu0.1+esm11
7:4.2.7-0ubuntu0.1+esm12
ffmpeg
Ubuntu:Pro:22.04:LTS
before 7:4.4.2-0ubuntu0.22.04.1+esm11, plus listed versions
7:4.4-6ubuntu57:4.4.1-2ubuntu17:4.4.1-3ubuntu17:4.4.1-3ubuntu27:4.4.1-3ubuntu3
Show 12 moreShow less
7:4.4.1-3ubuntu57:4.4.2-0ubuntu0.22.04.17:4.4.2-0ubuntu0.22.04.1+esm17:4.4.2-0ubuntu0.22.04.1+esm27:4.4.2-0ubuntu0.22.04.1+esm37:4.4.2-0ubuntu0.22.04.1+esm47:4.4.2-0ubuntu0.22.04.1+esm57:4.4.2-0ubuntu0.22.04.1+esm67:4.4.2-0ubuntu0.22.04.1+esm77:4.4.2-0ubuntu0.22.04.1+esm87:4.4.2-0ubuntu0.22.04.1+esm97:4.4.2-0ubuntu0.22.04.1+esm10
7:4.4.2-0ubuntu0.22.04.1+esm11
ffmpeg
Ubuntu:Pro:24.04:LTS
before 7:6.1.1-3ubuntu5+esm7, plus listed versions
7:6.0-6ubuntu17:6.0-9ubuntu17:6.1-2ubuntu17:6.1-3ubuntu17:6.1-4ubuntu1
Show 10 moreShow less
7:6.1-5ubuntu17:6.1.1-1ubuntu17:6.1.1-3ubuntu17:6.1.1-3ubuntu57:6.1.1-3ubuntu5+esm17:6.1.1-3ubuntu5+esm27:6.1.1-3ubuntu5+esm37:6.1.1-3ubuntu5+esm47:6.1.1-3ubuntu5+esm57:6.1.1-3ubuntu5+esm6
7:6.1.1-3ubuntu5+esm7
ffmpeg
Ubuntu:25.10
before 7:7.1.1-1ubuntu4.2, plus listed versions
7:7.1.1-1ubuntu17:7.1.1-1ubuntu27:7.1.1-1ubuntu37:7.1.1-1ubuntu47:7.1.1-1ubuntu4.1
7:7.1.1-1ubuntu4.2

History

History
RecordedChangedSources
affected, facts
affected, aliases, referencesOSV
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2025-59733 is a high vulnerability (CVSS 8.7) in Ffmpeg, published August 25, 2025. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.18%, the 7th percentile. Fixed in ffmpeg 8.0-r0.

References

Show 15 moreShow less
MoveEnter Open