FFmpeg CVE-2026-120247

Exploitation requires a vulnerable FFmpeg build (2.3 through 9.0.2) to decode an attacker-crafted Huffyuv (FFVHuff/HuffYUV) video in the packed BGR24 or BGRA pixel format whose packed-BGR bitstream/entropy data terminates early, so decode_slice() emits uninitialized s->temp[0] bytes into the frame. Limiting factors: the vector is local (AV:L) with passive user interaction (UI:P) - the attacker cannot trigger it remotely and must get a user or automated pipeline to process the malicious file; the leak is confined to specific BGR packed paths and short bitstreams; and the attacker must be able to observe the decoded output to actually recover the leaked heap bytes. Impact is confidentiality-only (information disclosure) with no code execution or crash.

This is a medium-severity information-disclosure issue, and the available signals agree on a moderate - not emergency - priority. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VC:H only) describes a local vector requiring passive user interaction, with no integrity or availability impact: an attacker cannot reach this over the network against a running service - a victim must decode an attacker-supplied Huffyuv file. The vuln.today decision label is 'this_month', not act_now or emergency, consistent with that reading. No EPSS score was supplied and the CVE is not listed in CISA KEV, so there is no public evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis' (the references are a vendor PR, the fix commit, source lines, and the VulnCheck advisory - none is exploit code). The main thing elevating real-world relevance is the enormous deployment footprint of FFmpeg itself, not the severity of a single bounded heap leak. Net: a genuine but non-critical issue - patch on a normal cadence rather than treat as an emergency. Note one tension to verify: the input marks PR:N (unauthenticated) yet the vector is AV:L with UI:P, so 'unauthenticated' here means no attacker credentials are needed but a local user must be induced to open or process the malicious media.

An attacker crafts a Huffyuv-encoded video in BGR24 or BGRA pixel format whose entropy/bitstream data ends early, then gets a victim to decode it with a vulnerable FFmpeg build (e.g. via a media player, transcoding service, or thumbnailer). During decode_slice(), uninitialized s->temp[0] heap bytes are written into the output frame; the attacker then observes the decoded pixels (e.g. in a re-encoded or thumbnailed output) to recover leaked heap memory. No public exploit code was identified, but the fix commit illustrates the exact trigger.