FFmpeg 2.1 through 9.0.2 Uninitialized Memory Leak via PCX Decoder
Affects FFmpeg 2.1 through 9.0.2 when the PCX decoder reads truncated RLE data. CVSS scores it 6.8 (medium). The checked facts list no fixed release.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 12/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fix or patch referenced
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
FFmpeg, the widely used multimedia framework, is affected through its PCX image decoder. A specially crafted PCX file with truncated compressed data can cause the decoder to expose uninitialized heap memory contents in the decoded image, potentially leaking sensitive information.
Read the original description
FFmpeg 2.1 through 9.0.2 contains a use of uninitialized resource vulnerability in the PCX decoder that allows attackers to leak heap memory through truncated RLE scanlines. Attackers can craft a PCX image whose RLE data ends early, causing pcx_decode_frame() to copy uninitialized av_malloc() buffer contents into visible decoded pixels.
What to do
Check whether your setup matches what the bug needs.
The PCX input ends before a scanline is fully decoded (truncated RLE data). The defect dates from the RLE support in the PCX decoder (regression since commit 50617fce07).Apply the patch listed under Evidence.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- FFmpeg FFmpeg
From 2.1 · through 9.0.2
Evidence 5
- Patch
- Report
- Repository
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-120244
What does this mean?
When a PCX file ends partway through a scanline, the FFmpeg decoder can leave part of that line unset. Uninitialized memory can then appear in the decoded output pixels.Source: code.ffmpeg.org
Am I affected, and how do I check?
The checked facts cover FFmpeg 2.1 through 9.0.2, back to the RLE support added in commit 50617fce07. The condition is PCX input that ends before a scanline is fully decoded. The FFmpeg version can be checked with the ffmpeg -version command.Source: code.ffmpeg.org
What should I do about it?
The checked facts do not name a fixed release, so no upgrade target can be confirmed from them. The upstream fix is the commit titled "avcodec/pcx: zero the rest of a scanline the input ends in", and the FFmpeg project's release notes should be checked for the first version that includes it.Source: code.ffmpeg.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data