An issue was discovered in GStreamer gst-plugins-good before 1.28.2. When parsing MP4 audio tracks, the isomp4 plugin's qtdemuxaudiocaps function does not sufficiently validate atom data before performing division operations, leading to denial of service due to integer division by zero.

A flaw was found in GStreamer's gst-plugins-good, specifically in the ...

An issue was discovered in GStreamer gst-plugins-good before 1.28.2. While parsing an MP4 file, the isomp4 plugin's qtdemuxparsechnl function may read past the end of a global array, potentially leading to information disclosure.

A flaw was found in GStreamer's adaptive streaming demuxers (HLS, DASH ...

GStreamer gst-plugins-good ships the rtph264depay element (gst/rtp/gstrtph264depay.c). MTAP16 (NAL type 26) and MTAP24 (NAL type 27) support was added in gst-plugins-good 1.28.0 (upstream commit 367cda03c9, 2025-10-08).

In gstrtph264depayprocess() the variable payloadlen is declared as gint (signed 32-bit). For the MTAP16/MTAP24 branch (lines 1380-1471), the code strips the 1-byte NAL type header (line 1387) and then unconditionally strips the 2-byte decoding-order-number base (DON base, line 1396) without first checking that at least 2 bytes remain. When the RTP payload is truncated (e.g., only 1 byte — just the NAL type), payloadlen goes negative (e.g., 1-1-2 = -2).

Bug 1 — Wrong loop guard (line 1398): aggregationunitsize is gsize (unsigned). The comparison 'while (payloadlen > aggregationunitsize)' performs an unsigned promotion of the signed payloadlen. A negative payloadlen (e.g., -2) becomes a very large unsigned value (0xFFFFFFFE on 32-bit), so the loop condition is TRUE and the loop body executes even though the packet is exhausted.

Bug 2 — Broken clamping (line 1427): Inside the loop, nalusize is read via GSTREADUINT16BE() from the payload pointer that is already past the end of the packet buffer (OOB heap read #1). The subsequent clamping guard 'if (nalusize > payloadlen)' is also a signed/unsigned comparison: nalusize is guint, payloadlen is gint (still negative). Negative payloadlen is promoted to a huge unsigned value, so the condition evaluates FALSE and nalusize is NOT clamped. nalusize may be up to 65535.

Bug 3 — memcpy from OOB (line 1441): memcpy(map.data + sizeof(syncbytes), payload, nalusize) reads nalusize (up to 65535) bytes from payload, which points past the end of the actual packet. This is the primary heap-buffer-over-read confirmed by ASan: READ of 48830 bytes at gstrtph264depay.c:1432.

The allocated output buffer (outbuf) has exactly nalusize+4 bytes; the DESTINATION is valid. Only the SOURCE is OOB. The content is then placed into the depayloaded output GstBuffer and forwarded downstream. In relay/transcode pipelines this becomes observable information disclosure. In all pipelines, the OOB read is likely to crash the process (SIGSEGV) when the read range extends into unmapped memory.

Affected: gst-plugins-good 1.28.0 through 1.28.8. Fixed in: 1.28.9 (unreleased as of 2026-10-28, private MR gstreamer-security !136). GStreamer advisory SA-2026-0095.

Reporter: Claude (Anthropic), Ada Logics. PSIRT ticket: PSIRTSUPT-29444.

An issue was discovered in GStreamer gst-plugins-good before 1.28.2. When parsing MP4 audio tracks, the isomp4 plugin's qtdemuxparsetrak function does not sufficiently validate atom data before performing division operations, leading to denial of service due to integer division by zero.

An issue was discovered in GStreamer gst-plugins-good before 1.28.2. While parsing an MP4 file, the isomp4 plugin's qtdemuxparseuuid function may read past the end of a heap-allocated buffer, allowing an attacker to disclose heap memory contents.

A flaw was found in GStreamer's gst-plugins-good MOV/MP4 demuxer. When ...

A flaw was found in GStreamer's gst-plugins-good isomp4 plugin. When processing a specially crafted MP4 or MOV file containing CEA-608 closed-caption data, an integer overflow in 32-bit unsigned arithmetic can bypass a bounds check in the caption parser. This leads to an out-of-bounds heap read of up to 244 bytes, which is then included in the downstream caption output. An attacker could exploit this by tricking a user into opening a malicious media file, potentially resulting in disclosure of adjacent heap memory or application crash.

GStreamer gst-plugins-good contains a vulnerability in the MOV/MP4 demuxer (qtdemux) closed-caption parser. In the extractccfromdata() function in subprojects/gst-plugins-good/gst/isomp4/qtdemux.c, when parsing a CEA-608 caption sample containing two atoms (cdat/cdt2), the bounds check for the second atom at line 6426 computes 'atomlength + newatomlength' using 32-bit unsigned arithmetic (both are guint32). An attacker can craft the second atom's length (newatomlength) such that this addition wraps around to a small value, bypassing the bounds check. The value 'newatomlength - 8' is then passed to converttos3341a() as a guint8 parameter (ccpairsize), truncating a large 32-bit value to at most 244 bytes. This causes converttos3341a() to read up to 244 bytes beyond the valid caption sample buffer, and the out-of-bounds heap data is included in the downstream caption output stream. Versions prior to gst-plugins-good 1.28.7 are affected. Fixed in gst-plugins-good 1.28.7. Security Advisory: GStreamer-SA-2026-0079. Upstream MR: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/mergerequests/12433. Reported by Seonwook Kim. PSIRT ticket: PSIRTSUPT-23503.

gst-plugins-good FLV demuxer (gst/flv/gstflvdemux.c): missing GstByteReader return checks in gstflvdemuxparsetagaudio/video before 1.28.2 when parsing Enhanced RTMP v2 tags; malformed FLV can crash the process (DoS). Fixed in gst-plugins-good 1.28.2 (MR !11244). Upstream GStreamer-SA-2026-0020 (2026-04-07). CVE CVE-2026-119843.

A 4-byte heap-buffer-overflow (out-of-bounds read) was found in gst-plugins-good's Matroska demuxer, in the function gstmatroskaparseflacstreamheaders() in gst/matroska/matroska-ids.c. When parsing FLAC codec private data embedded in a Matroska (MKV/WebM) container, the function iterates over FLAC metadata blocks. Each block has a 4-byte header (1 byte flags + 3 bytes length) followed by a body of 'len' bytes. The bounds check at line 309 validates 'off + len > codecdatasize' but the subsequent gstbuffernewmemdup() at line 314 copies 'len + 4' bytes (body + header). When off + len == codecdatasize, the guard passes but the memdup reads 4 bytes past the end of the heap-allocated codecdata buffer. The correct check should be 'off + 4 + len > codecdatasize'. This function is called from matroska-demux.c line 7397 when processing AFLAC audio tracks.

Affected versions: <= 1.28.5 Fixed in version: 1.28.6 (upcoming) Fix MR: https://gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/111 (GST-SA-2026-0073) Reporter: Yazan Balawneh, CyStack Security Team ASan confirmation on GStreamer 1.28.4, Kali Linux x8664: heap-buffer-overflow READ of size 42, 0 bytes after 42-byte region. PSIRT Ticket: PSIRTSUPT-19737

A 4-byte heap-buffer-overflow (out-of-bounds read) was found in gst-plugins-good's Matroska demuxer, in the function gstmatroskaparseflacstreamheaders() in gst/matroska/matroska-ids.c. When parsing FLAC codec private data embedded in a Matroska (MKV/WebM) container, the function iterates over FLAC metadata blocks. Each block has a 4-byte header (1 byte flags + 3 bytes length) followed by a body of 'len' bytes. The bounds check at line 309 validates 'off + len > codecdatasize' but the subsequent gstbuffernewmemdup() at line 314 copies 'len + 4' bytes (body + header). When off + len == codecdatasize, the guard passes but the memdup reads 4 bytes past the end of the heap-allocated codecdata buffer. The correct check should be 'off + 4 + len > codecdatasize'. This function is called from matroska-demux.c line 7397 when processing AFLAC audio tracks.

Affected versions: <= 1.28.5 Fixed in version: 1.28.6 (upcoming) Fix MR: https://gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/111 (GST-SA-2026-0073) Reporter: Yazan Balawneh, CyStack Security Team ASan confirmation on GStreamer 1.28.4, Kali Linux x8664: heap-buffer-overflow READ of size 42, 0 bytes after 42-byte region. PSIRT Ticket: PSIRTSUPT-19737