GStreamer-SA-2026-0015 reports integer overflows and division by zero in the jp2kdecimator element of gst-plugins-bad when it processes malformed JPEG 2000 codestreams. Insufficient bounds checks in size validation and tile configuration parsing permit multiplication overflows and a zero tile dimension to reach division. A crafted JPEG 2000 stream or media file can crash the GStreamer application, causing denial of service. Upstream identifies gst-plugins-bad versions before 1.28.2 as affected and 1.28.2 as the fixed release. The advisory was published on 2026-04-07 and does not identify the original reporter or supply a public proof of concept. This record is based on the upstream advisory and release notes; no independent source review or dynamic reproduction has been completed. Advisory: https://gstreamer.freedesktop.org/security/sa-2026-0015.html

GStreamer Security Advisory GStreamer-SA-2026-0017 reports an integer overflow in the gst-plugins-bad H.266/VVC parser while parsing profile, tier, and level fields from malformed H.266 streams. The resulting stack-based buffer overflow may crash an application processing malicious media and could possibly allow code execution. Upstream lists gst-plugins-bad versions 1.25.1 through versions before 1.28.2 as affected; version 1.28.2 contains the fix. The local verification report confirmed the code pattern by static analysis but did not confirm the exact exploit path.

gst-plugins-bad contains a NULL pointer dereference in the H.264 Subset SPS (Sequence Parameter Set) MVC (Multiview) extension parser. The vulnerable function is gsth264parsespsmvcdata() in subprojects/gst-plugins-bad/gst-libs/gst/codecparsers/gsth264parser.c. The function sets sps->extensiontype = GSTH264NALEXTENSIONMVC at line 2071 before any heap allocations (mvc->view, mvc->levelvalue, applicableop, targetviewid). If any subsequent READ macro fails (truncated bitstream, out-of-range value), control jumps to the 'error:' label at line 2139 which calls gsth264spsclear(sps). This dispatches to gsth264spsmvcclear(sps) because extensiontype is already MVC. The cleanup function iterates over heap-allocated sub-structures that may be partially or wholly uninitialized. A NULL dereference can occur when the cleanup traverses these structures.

Affected upstream versions: gst-plugins-bad < 1.28.2. Fixed in gst-plugins-bad 1.28.2 (upstream MR !11240).

Upstream: GStreamer-SA-2026-0013 (2026-04-07).

GStreamer's gst-plugins-bad provides the H.265 (HEVC) bitstream parser in subprojects/gst-plugins-bad/gst-libs/gst/codecparsers/gsth265parser.c. In the function gsth265parsespsext() at approximately line 2297, when parsing the SPS SCC (Screen Content Coding) extension, the code computes the upper bound for spsnumpalettepredictorinitializerminus1 as 'palettemaxsize + deltapalettemaxpredictorsize - 1'. If an attacker crafts a bitstream where both palettemaxsize and deltapalettemaxpredictorsize are 0 (legal values per their individual READUEMAX constraints), this subtraction produces 0xFFFFFFFF via unsigned integer underflow. The READUEMAX macro checks 'val > max' using guint32 comparison, so 0xFFFFFFFF as max accepts any guint32 value. The field spsnumpalettepredictorinitializerminus1 is stored in a guint8, so the value is truncated to 0..255. If the truncated value exceeds 127, the subsequent loop 'for (i = 0; i < num; i++) READUINT32(nr, spspalettepredictorinitializer[comp][i], numbits)' writes past the end of the guint32 spspalettepredictorinitializer[3][128] array, causing a heap buffer overflow into adjacent GstH265SPSSCCExtensionParams and GstH265SPS struct members. This corrupts the GstH265SPS object stored in the parser's static sps[] array.

Affected versions: gst-plugins-bad < 1.28.1. Fix: gst-plugins-bad 1.28.1 adds a guard 'if (palettemaxsize + deltapalettemaxpredictorsize == 0) goto error' before the bound computation. Advisory: GStreamer-SA-2026-0012. Reporter: GStreamer project (upstream self-reported).

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.

GStreamer's asfmux plugin (gst-plugins-bad) contains a heap out-of-bounds write in the ASF header buffer allocation path. The functions contentdescriptioncalcsizefortag() (line 429) and addmetadatatagsize() (line 539) in subprojects/gst-plugins-bad/gst/asfmux/gstasfmux.c compute the UTF-16LE buffer size for string metadata tags using the formula 2 (1 + gutf8strlen(text, -1)). This counts Unicode code points and assumes each maps to one 16-bit UTF-16 code unit. However, non-BMP characters (U+10000 and above, e.g. emoji) require UTF-16 surrogate pairs (4 bytes per character). The write path in gstasfmuxwritestringwithsize() (line 881) uses gconvert() which produces the correct (larger) UTF-16LE byte count. The header buffer is allocated at gstasfmuxstartfile() (line 1332) using the pre-computed sizes. The resulting under-allocation is 2 bytes per non-BMP code point. The overflowing bytes are attacker-derived UTF-16LE content written via memcpy() at line 898.

The issue affects GStreamer versions containing the asfmux plugin in gst-plugins-bad. Reproduced at commit 4cb910d273bef5445c90e77e7b781ab99e236e1f (main branch). The affected size calculation is unchanged on current main.

Fix: Not yet available upstream (reported privately to GStreamer security team, awaiting triage).

Reporter: Bruno Fournier (xxtqqtx) PSIRT Ticket: PSIRTSUPT-24645

A flaw was found in GStreamer gst-plugins-bad (adpcmdec). The IMA/DVI ADPCM decoder validated the per-block sample count with (nsamples - channels) % 8 == 0, which does not ensure alignment with the decode loop that writes 8 channels samples per iteration. A crafted multi-channel IMA ADPCM WAV can pass this check and cause a heap out-of-bounds write of decoded sample values that are partially derived from attacker-controlled compressed audio data. The adpcmdec element is auto-plugged by decodebin/playbin, so processing untrusted media (players, thumbnailers, transcoders) can trigger the issue, resulting in application crash, denial of service, memory corruption, or potentially code execution. Fixed upstream in gst-plugins-bad 1.28.6 (GStreamer-SA-2026-0077).

A stack buffer overflow was found in GStreamer's DTLS plugin (gst-plugins-bad). In opensslverifycallback(), the peer certificate Subject DN is printed using X509NAMEprintex() into a memory BIO, then read via BIOread() into a fixed gchar buf[2048] on the stack. The number of bytes read comes directly from the X509NAMEprintex() return value without bounds checking against the buffer size.

A remote DTLS peer can send a certificate with an oversized Subject DN (many long OU fields) so that the formatted output exceeds 2048 bytes, causing a stack buffer overflow during the DTLS handshake.

File: subprojects/gst-plugins-bad/ext/dtls/gstdtlsconnection.c Function: opensslverifycallback() (lines 1136-1144)

Exploitability analysis: - The overflow content is TEXT ONLY (X509NAMEprintex with XNFLAGMULTILINE escapes all binary/control characters to printable ASCII sequences like \XX) - Stack canary (-fstack-protector-strong) terminates the process before return address corruption is exploitable - Arbitrary byte injection is impossible: null bytes become \00 (3 printable chars), high-bit bytes become \XX - RCE is NOT achievable. Maximum impact is denial of service (crash)

Attack vector: Unauthenticated remote DTLS-SRTP/WebRTC peer triggers this during handshake by presenting a crafted certificate. No user interaction required.

Affected: GStreamer gst-plugins-bad (reproduced on 1.28.3) Fixed: Planned for GStreamer 1.28.5 Fix MR: https://gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/99 Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5172 (confidential) Advisory: GST-SA-2026-0062

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

A heap buffer overflow was found in GStreamer's rfbsrc plugin (gst-plugins-bad, librfb component). In rfbdecoderfillrectangle(), when a malicious RFB/VNC server advertises a 16bpp RGB565 framebuffer and sends a Hextile-encoded update, the background fill path computes the destination offset using decoder->bytespp (2 bytes) but casts the destination to guint32 and writes one 32-bit value per pixel. For bytespp == 2, the framebuffer is allocated as 2 bytes per pixel, but the fill loop writes and advances by 4 bytes per pixel, causing a heap out-of-bounds write.

File: subprojects/gst-plugins-bad/gst/librfb/rfbdecoder.c Function: rfbdecoderfillrectangle()

A remote attacker controlling an RFB/VNC server can trigger this by having a client connect using rfbsrc. The demonstrated impact is heap-buffer-overflow and process abort. Since this is a heap out-of-bounds write on remote input, integrity impact is possible though code execution has not been demonstrated.

Affected: GStreamer gst-plugins-bad (reproduced on 1.28.3) Fixed: Planned for GStreamer 1.28.5 Fix MR: https://gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/100 Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5173 (confidential) Advisory: GST-SA-2026-0063

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

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

A global buffer overflow (out-of-bounds read) was found in GStreamer's gst-plugins-bad H.266/VVC parser in the gsth266parsevuiparameters() function at subprojects/gst-plugins-bad/gst-libs/gst/codecparsers/gsth266parser.c:561. The aspectratioidc field is read as an 8-bit value (0-255) from the H.266 bitstream and used directly as an array index into the aspectratios[] array, which contains only 17 entries (indices 0-16). When aspectratioidc is 17-254, the code performs an 8-byte out-of-bounds read from the .data section (reading two guint fields: parn and pard). The H.265 parser (gsth265parser.c) contains the correct bounds check (else if (vui->aspectratioidc <= 16)) which is missing in the H.266 implementation, indicating this was an oversight during porting. The leaked values are stored in GstH266VUIParams and propagated to GStreamer caps as pixel-aspect-ratio metadata, affecting video scaling in downstream components. Upstream maintainer Sebastian Dröge confirmed the vulnerability is valid and that the proposed patch is correct. The bug affects all versions containing the H.266 parser. Reported by Dr. Faruk Kazi and Ramesh Adhikari from CoE-CNDS Lab, VJTI, Mumbai, India. Upstream tracking: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5109

PSIRT Ticket: PSIRTSUPT-17586

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.

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.

An out-of-bounds read vulnerability was found in the VA JPEG decoder in GStreamer's gst-plugins-bad. The JPEG parser reads a segment length value from the bitstream without validating it against available data. A remote attacker could trick a user into opening a specially crafted JPEG file, causing downstream parsing to read beyond the provided input buffer, leading to a crash or potential information disclosure.

GStreamer VA JPEG decoder out-of-bounds read vulnerability. In gstjpegparser.c (gst-plugins-bad), the gstjpegparse() function reads a segment length from the bitstream without validating it against available data. The VA JPEG decoder path trusts this untrusted seg->size value and constructs a byte reader over an inflated range, reading past the buffer. The code's own comment explicitly acknowledges this: "a valid segment may be returned with a length that exceeds the available data." Upstream confirmed by maintainer Sebastian Dröge (2026-06-02), who noted it is "actually a bug in the VA JPEG decoder in gst-plugins-bad" and "an OOB read that could lead to a crash or possibly information disclosure." Fix planned for GStreamer 1.28.4 or 1.28.5. Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5104 (confidential). Reported via PSIRTSUPT-17026 by JUNYI LIU / Moss 1.

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.

GStreamer AV1 tilelistobu parser abort vulnerability. The gstav1parserparsetilelistobu() function in gstav1parser.c (gst-plugins-bad) passes a byte count to gstbitreaderskip(), which expects a bit count. This causes parser desynchronization and a deterministic gassert abort when processing a specially crafted AV1 media file. A 21-byte test case is sufficient to trigger the crash. Upstream confirmed by maintainer Sebastian Dröge (2026-06-02). Fix planned for GStreamer 1.28.4 or 1.28.5. Upstream issue: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5103 (confidential). Reported via PSIRTSUPT-17026 by JUNYI LIU / Moss 1.