FFmpeg EUVD-2026-95081

Exploitation requires the input media to carry HDR10+ dynamic metadata with tone_mapping_flag set to 0, delivered through a Matroska T.35 BlockAdditional packet or an HEVC/AV1 SEI message, and it requires the victim to actively remux or transcode that file with FFmpeg 9.0.2 or earlier (UI:P - the leak only occurs on processing, not on mere receipt). The leak is bounded to at most three uninitialized bytes per serialization, so it is not a bulk disclosure primitive. Limiting factors: the attacker cannot trigger it remotely against a listening service, exploitation depends on a pipeline that re-serializes HDR10+ metadata, and the attacker only recovers data that happens to occupy those freed/uninitialized bytes, with no control over its contents.

This is a genuinely low-to-moderate priority issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 score of 4.8 (Medium) is driven by AV:L (local - the attacker does not reach the vulnerable code over a network but must get a crafted file onto a system where FFmpeg processes it), UI:P (passive user interaction - a victim or automated pipeline must remux/transcode the malicious input), and VC:L with VI:N/VA:N (only a small, bounded confidentiality leak of up to three uninitialized bytes; no integrity or availability impact). No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation probability signals are all absent or negative; per the rules, absence of these is not treated as a defect. The CWE-908 (use of uninitialized resource) classification and the description agree with the low-impact CVSS rating: this leaks at most three bytes per invocation into output files, not a bulk memory-disclosure primitive. The practical risk is therefore an information-leak concern primarily relevant to shared/multi-tenant transcoding pipelines (e.g. hosting platforms that ingest user-supplied media) where leaked process bytes could accumulate or occasionally expose sensitive data; for most single-user or trusted-input deployments the real-world risk is minimal. One nuance worth verifying: the vector is AV:L, yet FFmpeg is very commonly used server-side to process untrusted uploaded media, which functionally resembles remote-supplied input even though CVSS scores the code path as local - defenders running ingestion services should weight this higher than the raw AV:L suggests.

An attacker crafts a media file embedding HDR10+ dynamic metadata (via Matroska T.35 BlockAdditional or HEVC/AV1 SEI) with tone_mapping_flag set to 0, then submits it to a service or user that remuxes or transcodes it with FFmpeg through 9.0.2. During serialization by av_dynamic_hdr_plus_to_t35(), up to three uninitialized payload bytes of process memory are written into the output file, which the attacker later retrieves and inspects for leaked data. No public exploit code was identified at time of analysis, and exploitation requires the victim to process the file (UI:P), limiting it to opportunistic or pipeline-targeted abuse.