CVE-2026-18649

CVE-2026-18649 targets an unbounded reassembly buffer in GStreamer's rtph264depay and rtph265depay elements. Attackers can send a continuous stream of RTP fragments without proper end markers, causing the depayloader to allocate memory indefinitely until the process exhausts available resources. This is a denial-of-service vulnerability exploitable remotely on any GStreamer-based application processing untrusted RTP streams — video conferencing software, media servers, streaming pipelines, and IoT devices using GStreamer for protocol handling. The critical insight here is that this is not an isolated coding mistake — it's a structural pattern. The same unbounded reassembly logic that makes rtph264depay vulnerable almost certainly exists in other RTP depayloaders within the GStreamer tree: rtpg722depay, rtpg726depay, rtpopusdepay, rtpmpadepay, and rtpgstdepay all perform fragment reassembly and none have explicit buffer size limits enforced at the framework level. The vulnerability exists because GStreamer's plugin architecture places resource commitment decisions entirely on individual element authors. There's no framework-level guard that says "this buffer cannot exceed X regardless of what your element logic decides." What you should do: First, identify every GStreamer-based application or device in your environment that processes RTP input from untrusted sources. Second, check whether your GStreamer version includes the rtph264depay and rtph265depay patches — if you're on a version predating the fix, treat any RTP input from the network as potentially adversarial. Third, and more importantly, assume other depayloaders in your version have the same class vulnerability until proven otherwise. Consider implementing application-layer resource monitoring that kills the pipeline if memory consumption by RTP-handling processes exceeds a defined threshold — this is a compensating control that works regardless of which depayloader contains the flaw. The deeper lesson is that GStreamer's flexibility — its competitive advantage — creates this attack surface by default. The project has no systematic mechanism to translate a discovered vulnerability in one depayloader into a signal that prompts review of functionally similar elements. When rtph264depay gets patched, rtpopusdepay doesn't automatically get audited. This means the blast radius of any single fix is limited to that specific element, leaving the broader depayloader family vulnerable until each one is individually found and reported.

Reviewed through automated stages and approved by a human before publication.