464 results (0.004 seconds)

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

16 Apr 2026 — FFmpeg before 8.1 has an integer overflow and resultant out-of-bounds write via CENC (Common Encryption) subsample data to libavformat/mov.c. • https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22348 • CWE-190: Integer Overflow or Wraparound •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

06 Oct 2025 — It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2. When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. • https://b.corp.google.com/issues/440183164 • CWE-416: Use After Free •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

06 Oct 2025 — 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", "... • https://b.corp.google.com/issues/436511754 • CWE-787: Out-of-bounds Write •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

06 Oct 2025 — 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 ... • https://b.corp.google.com/issues/436510316 • CWE-787: Out-of-bounds Write •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

06 Oct 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. When ... • https://b.corp.google.com/issues/436510153 • CWE-787: Out-of-bounds Write •

CVSS: 9.8EPSS: 0%CPEs: 2EXPL: 0

06 Oct 2025 — When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it. Frames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution. This codec can encode the frame contents using a run-length encoding algorithm. There are no checks that the decoded frame fits in the allocated buffer, leading to a heap-buffer-overflow. process_frame_obj initializes the buffers based on the ... • https://issuetracker.google.com/434637586 • CWE-787: Out-of-bounds Write •

CVSS: 9.8EPSS: 0%CPEs: 2EXPL: 0

06 Oct 2025 — When parsing the header for a DHAV file, there's an integer underflow in offset calculation that leads to reading the duration from before the start of the allocated buffer. If we load a DHAV file that is larger than MAX_DURATION_BUFFER_SIZE bytes (0x100000) for example 0x101000 bytes, then at [0] we have size = 0x101000. At [1] we have end_buffer_size = 0x100000, and at [2] we have end_buffer_pos = 0x1000. The loop then scans backwards through the buffer looking for the dhav tag; when it is found, we'll ca... • https://issuetracker.google.com/433513232 • CWE-787: Out-of-bounds Write •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 0

06 Oct 2025 — When calculating the content path in handling of MPEG-DASH manifests, there's an out-of-bounds NUL-byte write one byte past the end of the buffer.When we call xmlNodeGetContent below [0], it returns a buffer precisely allocated to match the string length, using strdup internally. If this buffer is not an empty string, it is assigned to root_url at [1].If the last (non-NUL) byte in this buffer is not '/' then we append '/' in-place at [2]. This will write two bytes into the buffer, starting at the last valid... • https://issuetracker.google.com/433502298 • CWE-787: Out-of-bounds Write •

CVSS: 7.2EPSS: 0%CPEs: 1EXPL: 0

09 Sep 2025 — 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. It was discovered that FFmpeg incorrectly handled the return values of functions in its Firequalizer filter and in the HTTP Live Streaming implementation, leading to a NULL pointer dereference. If a user was tricked into loading a crafted media file, a remote attacker could possibly use this issue to make FFm... • https://github.com/google/security-research/security/advisories/GHSA-39q3-f8jq-v6mg • CWE-122: Heap-based Buffer Overflow •

CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0

18 Feb 2025 — FFmpeg git-master before commit d5873b was discovered to contain a memory leak in the component libavutil/mem.c. • https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/d5873be583ada9e1fb887e2fe8dcfd4b12e0efcd • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •