The CVSS 7.6 score for CVE-2026-19387 almost certainly understates the actual risk. This is a heap out-of-bounds write in GStreamer's adpcmdec plugin, and the root cause is a stride calculation mismatch when handling multi-channel WAV audio. The bug isn't triggered by malformed input — it's triggered by any valid multi-channel WAV file where the per-block sample count exceeds what the channel-interleaved stride math accounts for. That makes it deterministic for 6-channel WAV files that conform to the specification.
The CVSS assumes you need a malicious file and complex heap grooming to exploit this. That's wrong for a large class of deployments. GStreamer runs in embedded contexts — IP cameras streaming to NVRs, VoIP applications transcoding audio, WebRTC browsers processing incoming RTP — where the 'prerequisite' of getting multi-channel audio into the decoder isn't an obstacle at all. The attacker already controls the byte stream. They're not exploiting a edge case; they're using the codec exactly as designed.
Worse, ADPCM decoders occupy a maintenance graveyard. This code lives in gst-plugins-bad for a reason — it's legacy infrastructure that was written when ADPCM mattered commercially, preserved as functional rather than actively maintained. The multi-channel support was likely added as a generalization without rigorous audit of the stride calculation. Nobody's fuzzing ADPCM decoders with multi-channel inputs, which means this bug may have been exploitable for years before discovery.
What to do: First, determine whether any of your GStreamer pipelines process multi-channel audio from untrusted sources — that's the trigger condition. Second, inventory where adpcmdec runs in production; IP cameras, NVRs, conferencing systems, and media processing servers are high-exposure targets. Third, apply the patch when available — but recognize that remediation lag in embedded devices runs in years, not days. The exposure window here isn't measured from disclosure to patch deployment; it's measured from when multi-channel ADPCM processing first hit production to when it's universally fixed. That window is likely already years wide.