A flaw was found in gst-plugins-base. A heap buffer overflow can be triggered when processing video buffers whose attached GstVideoMeta metadata declares plane strides and offsets that exceed the actual backing memory allocation. The metadata is not range-checked during deserialization, and the video frame mapping code does not verify that the declared plane geometry fits within the buffer before allowing consumers to read or write video data. A local attacker who controls the sending side of a GStreamer inter-process IPC pipeline can deliver a crafted buffer carrying fabricated strides, causing the receiving process to read or write beyond heap boundaries. Successful exploitation can cause a denial of service or potentially allow code execution within the affected process.

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

A flaw was found in the SRT and WebVTT subtitle parser in GStreamer's ...

A flaw was found in GStreamer's gst-plugins-bad package. A use of unin ...

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

A flaw was found in GStreamer's MXF demuxer plugin (gst-plugins-bad). ...

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

GStreamer-SA-2026-0023: The SRT/WebVTT subtitle parser (subparse) uses regular-expression matching and replacement with quadratic time complexity for long lines. A crafted subtitle file can cause excessive CPU use and application unresponsiveness. Fixed in gst-plugins-base 1.28.2.

GStreamer-SA-2026-0025: Insufficient validation in MOV/MP4 demuxer uncompressed video handling. Advisory details and affected version range were not available from the page fetch; the OSIM record is based on the published advisory title and date.

gst-plugins-bad mxfdemux (gst/mxf/mxfdemux.c) contains at least five heap-buffer-overflow READ paths introduced in GStreamer 1.20.0 by the index-table refactor (commit ac483b2384, 2021-07-21). Root cause CWE-129: findeditentry() and findentryforoffset() use deltaid and slice as array indices without validating against ndeltaentries and slicecount.

Affected upstream GStreamer versions: >= 1.20.0, fixed in 1.28.9 (unreleased as of 2026-10-30). Upstream advisory SA-2026-0093; fix in gstreamer-security MR !131.

PSIRT ticket: PSIRTSUPT-29601.

Reporter: Sebastian Dröge, Centricular Ltd.

gst-plugins-bad (GstCodecparsers library) contains a use-of-uninitialized-variable (CWE-457) in gsth265parsevps() in gst-libs/gst/codecparsers/gsth265parser.c. When a VPS NAL unit declares more than one HRD parameter set (vpsnumhrdparameters >= 2), the workaround loop at lines 2152-2165 processes each extra set (i >= 1) into a local GstH265HRDParams hrdparams variable declared at line 2155 that is never zero-initialized before being passed to gsth265parsehrdparameters(). That function sets only three fields to defaults and leaves all other fields as stack garbage, which steers further parsing (including gsth265parsesublayerhrdparameters() at line 439). Bug introduced in upstream GStreamer 1.16.0 (commit 52f2054386). Fix targeted for upstream 1.28.9 (not yet merged as of 2026-10-30; private gstreamer-security MR !132). GStreamer security advisory SA-2026-0094. PSIRT support ticket PSIRTSUPT-29600. Reporter: Sebastian Dröge, Centricular Ltd.

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.

A logic vulnerability was found in GStreamer's webrtcbin component (gst-plugins-bad). The checksdpcrypto() function in webrtcsdp.c contains an inverted boolean condition at lines 128-134 that causes it to accept remote SDP offers or answers that lack the required a=fingerprint attribute, while incorrectly rejecting those that include it.

The check reads: if (!ISEMPTYSDPATTRIBUTE(messagefingerprint) && !ISEMPTYSDPATTRIBUTE(mediafingerprint)) Which means: if BOTH fingerprints ARE present, reject. The correct logic should reject when both are ABSENT.

File: subprojects/gst-plugins-bad/ext/webrtc/webrtcsdp.c Function: checksdpcrypto()

An attacker who can intercept and modify the WebRTC signaling channel can remove a=fingerprint attributes from SDP messages. The vulnerable webrtcbin will accept the modified SDP, bypassing the RFC 8122 fingerprint-to-DTLS-certificate binding. This weakens defenses against man-in-the-middle attacks on media streams.

Practical impact is limited: exploitation requires MITM on the signaling channel (typically TLS-protected), and the DTLS layer may still independently validate certificates. This is a defense-in-depth bypass, not a complete cryptographic break.

Affected: GStreamer gst-plugins-bad (reproduced on 1.28.3 and current main) Fixed: Planned for GStreamer 1.28.5 Fix MR: https://gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/98 Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5171 (confidential)

Reporter: Clouditera Security; Z.ai Security; NSFOCUS PSIRT Ticket: PSIRTSUPT-19091

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 flaw was found in GStreamer's H.266 codec parser library (libgstcodecparsers). An out-of-bounds write vulnerability exists in the DCI parsing function, where a reserved field value is incorrectly accepted, causing the parser to write beyond the bounds of an internal structure. An attacker could exploit this by providing a specially crafted H.266 bitstream to a third-party application that uses this library API, potentially causing a crash or memory corruption. No standard GStreamer pipeline element currently invokes the affected code path.

An incomplete fix for CVE-2024-47778 allows an out-of-bounds read in gstwavparseadtlchunk() function. The patch added a size validation check lsize + 8 > size, but it does not account for the GSTROUNDUP2(lsize) used in the actual offset calculation. When lsize is an odd number, the parser advances more bytes than validated, causing OOB read.

A NULL pointer dereference flaw was found in GStreamer's RTSP support library. The vulnerability occurs while parsing an Authorization or WWW-Authenticate header that uses Digest authentication. Specially crafted whitespace placement around a parameter's terminator can cause an internal length calculation to underflow, leading to a crash of the process parsing the header. On an RTSP server this can be triggered by a remote, unauthenticated attacker sending a single malformed request when the server has authentication enabled; the same flaw can also be triggered against an RTSP client by a malicious or compromised RTSP server. Successful exploitation results in a denial of service (application crash) and has no confirmed impact on confidentiality or integrity.

A flaw was found in GStreamer's RealMedia demuxer in the gst-plugins-ugly package. When processing a RealMedia file containing a specially crafted FILEINFO metadata section, the demuxer parses variable-name and variable-value pairs using reskippascalstring() without validating that offsets remain within the mapped buffer. Additionally, the element count controlling the parsing loop is read from attacker-controlled data without validation, which can cause an infinite loop. A crafted RealMedia file can cause the application to crash, hang, or potentially read limited adjacent memory contents.

A vulnerability was found in the GStreamer RealMedia demuxer (gst-plugins-ugly). When processing a RealMedia (.rm) file, the demuxer parses MDPR (media properties) chunks to configure audio streams. For audio stream header versions 4 and 5, the parser reads fields such as codec type, packet size, sample rate, channel count, and extra codec data length from fixed offsets within the chunk without first checking that the chunk contains enough data. If a malicious file provides an MDPR chunk that is too small to contain a complete audio stream header, the parser reads beyond the end of the buffer. This can cause the application to crash. In some cases, bytes read past the buffer boundary may be incorporated into stream metadata, which could result in limited information disclosure.

GStreamer pcapparse element multiple out-of-bounds read vulnerabilities. In gstpcapparse.c (gst-plugins-bad), multiple issues exist in PCAP record parsing: (1) At line 465-466, srcport/dstport are read from bufproto without verifying sufficient data exists after the IP header for TCP/UDP header fields. (2) At line 485, payloadsize = ippacketlen - ipheadersize - len trusts the ippacketlen field from the IP header. A spoofed value larger than the actual buffer yields a payloadsize exceeding available data. (3) When payloadsize is computed from an untrusted IP length field, downstream gets data from the next PCAP record. Upstream confirmed by maintainer Sebastian Dröge (2026-06-02): "Confirmed, OOB reads. Can only be triggered in specially crafted GStreamer pipelines (as built for debugging purposes) on specially crafted data, very unlikely to cause problems in reality." Fix planned for GStreamer 1.28.4. Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5106 (confidential). Reported via PSIRTSUPT-17026 by JUNYI LIU / Moss (moss80199).

A 1-byte heap out-of-bounds read vulnerability exists in the gsth264parseprocessnal() function in subprojects/gst-plugins-bad/gst/videoparsers/gsth264parse.c. The function processes H.264 NAL units including GSTH264NALSLICEEXT (NAL type 20) for MVC/SVC extension slices. At line 1132, the code dereferences (nalu->data + nalu->offset + nalu->headerbytes) to check the firstmbinslice flag without first verifying that nalu->size > nalu->headerbytes. For extension slice types, headerbytes is set to 4 (1 byte base + 3 bytes extension header per gsth264parser.c:243). A malformed NAL unit with exactly size==4 passes the minimum size check (size >= 2 at line 999) but triggers a 1-byte read at offset 4, which is beyond the allocated buffer. The same bounds check pattern is correctly implemented in gsth264parsecollectnal() at line 1259 with if (nalu->size > nalu->headerbytes). The vulnerability affects GStreamer 1.x versions (tested against git version 1.29.1.1). Upstream maintainer Sebastian Droege confirmed the vulnerability via GitLab work item 5108. Reported by Dr. Faruk Kazi, Ramesh Adhikari, and Ariba Afroz from CoE-CNDS Lab, VJTI, Mumbai, India. PSIRT Ticket: PSIRTSUPT-17585.

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.

A flaw was found in the GStreamer multimedia framework's ASF muxer plugin (asfmux). When writing string metadata tags containing Unicode characters outside the Basic Multilingual Plane (such as emoji) to an ASF container, the plugin incorrectly calculates the buffer size needed for the UTF-16LE representation. The size calculation assumes each Unicode code point requires 2 bytes, but non-BMP characters require 4 bytes (surrogate pairs). This leads to a heap out-of-bounds write when the actual UTF-16LE conversion is written into the undersized buffer. An attacker could exploit this by providing media with crafted metadata tags to an application that transcodes or remuxes to ASF format while preserving metadata, potentially causing a denial of service or limited memory corruption.

A flaw was found in the GStreamer ASF demuxer (gst-plugins-ugly). The Simple Index object parser reads an attacker-controlled entry count from the media and allocates an index table of that size with gnew0 without first clamping the count to the bytes remaining in the object. A crafted ASF, WMV, or WMA file can therefore request a very large heap allocation (on the order of tens of gigabytes of address space). When the allocation cannot be satisfied, or under memory limits, the application can abort or be terminated, resulting in denial of service. The parse loop stops when payload is exhausted, and GLib allocation helpers do not return an undersized buffer; this is not a heap buffer overflow.

A denial of service vulnerability was found in GStreamer's AV1 codec parser in gst-plugins-bad. The gstav1parserparsetilelistobu() function passes a byte count to a bit-reader API that expects a bit count, causing parser desynchronization. A remote attacker could trick a user into opening a specially crafted AV1 media file, triggering an assertion abort and causing the application to crash.

A flaw was found in the GStreamer gst-plugins-bad package. When processing a malformed H.266/VVC video stream with a crafted aspect ratio indicator value, the H.266 parser performs an out-of-bounds read of up to 8 bytes from adjacent memory. This flaw allows an attacker to craft a malicious H.266 video file or stream that, when processed by a GStreamer-based application, could leak limited memory contents through video metadata, potentially exposing sensitive information from the application's address space.

An out-of-bounds write vulnerability was found in GStreamer's H.266/VVC PPS picture partition parser in gst-plugins-bad. In the multi-slice-in-tile processing of gsth266parserparsepicturepartition() (gsth266parser.c), the loop iterates without checking that the slice index stays within bounds, writing past three fixed-size arrays (sliceheightinctus, slicetopleftctux, slicetopleftctuy) in the GstH266PPS structure. While the initial proof-of-concept demonstrated a 4-byte out-of-bounds write, the code permits larger writes across multiple iterations. A crafted H.266/VVC media file can trigger this vulnerability.

A stack buffer overflow flaw was found in the GStreamer H.265 codec parser library (gst-plugins-bad). When parsing a buffering period SEI message, the parser uses an incorrect loop bound derived from cpbcntminus1[i] (the loop index) instead of the sub-layer 0 CPB count cpbcntminus1[0] from the referenced Sequence Parameter Set. A crafted H.265 video file or stream can cause the parser to write beyond the bounds of stack-allocated CPB delay arrays, resulting in a crash or potential stack memory corruption.

A flaw was found in GStreamer gst-plugins-ugly (asfdemux). The ASF demuxer performed arithmetic on attacker-controlled length and size fields from ASF/WMV/WMA headers using 32-bit unsigned operations without adequate overflow and underflow checks. In gstasfdemuxprocessmetadata(), summing namelen and datalen could wrap, bypassing the available-data check and causing gconvert() to read beyond the heap buffer during UTF-16LE to UTF-8 conversion. Related underflow issues in other header parsers similarly produced oversized lengths and out-of-bounds reads. Because asfdemux is auto-plugged by playbin and decodebin, processing a crafted file can crash the application (denial of service) and may enable limited heap information disclosure via metadata handling. Fixed upstream in gst-plugins-ugly 1.28.6 (GStreamer-SA-2026-0075).

A heap buffer overflow vulnerability was found in GStreamer's rfbsrc plugin. When a client connects to a malicious RFB/VNC server that advertises a 16bpp framebuffer and sends Hextile-encoded updates, the Hextile background fill path writes 32-bit pixel values into a buffer allocated for 16-bit pixels. This type mismatch causes an out-of-bounds heap write that can lead to denial of service (process crash) and potential memory corruption.