CVE-2026-58049: FFmpeg RASC Decoder Heap Corruption Vulnerability

Technical summary

The vulnerability exists in FFmpeg's decode_dlta function within libavcodec/rasc.c, which handles RASC-encoded video frames. The decoder performs 32-bit memory operations at the row cursor position before validating the NEXT_LINE row boundary. Additionally, DLTA region validation uses pixel units rather than byte units, causing a mismatch on indexed color (PAL8) frames where pixel size differs from byte addressing. This combination permits bitstream-controlled out-of-bounds heap writes and adjacent out-of-bounds reads, corrupting adjacent heap structures and potentially enabling arbitrary code execution.

Business impact

Organizations using FFmpeg to process untrusted video content face risk of system compromise. Media streaming platforms, video transcoding services, and any application that decodes RASC-encoded video without strict input validation could be exploited through malicious media files. Successful exploitation may lead to unauthorized access, data theft, or denial of service. The vulnerability is particularly concerning in cloud environments where processing cost and resource contention can amplify the impact of a compromised worker process.

Affected systems

FFmpeg and any software built on libavcodec that decodes RASC video format (FourCC RASC) are affected. This includes custom applications and forks of FFmpeg. The vendor product list was not provided in available advisories; organizations should check whether their media processing pipelines or dependencies include FFmpeg RASC decoder support.

Exploitability

Exploitation requires only network access and no user privileges or interaction beyond decoding a crafted media file. The attack surface is broad for any system processing untrusted video input. However, exploitation complexity depends on heap layout predictability and the ability to leverage heap corruption toward code execution; memory protections (ASLR, heap hardening) raise the bar for reliable exploitation but do not prevent the out-of-bounds access itself.

Remediation

Apply the latest FFmpeg release containing the fix to the RASC decoder. Verify that row boundary validation occurs before memory operations and that DLTA region size calculation accounts for the byte-size of pixels on indexed color frames. Until patching is complete, restrict decoding of RASC-encoded video or apply input validation to reject RASC streams from untrusted sources.

Patch guidance

Check FFmpeg's official releases and security advisories for a patched version addressing CVE-2026-58049. The fix should modify decode_dlta in libavcodec/rasc.c to perform boundary checks before read/write operations and correct the DLTA region validation logic for PAL8 frames. Verify the specific version number against the vendor advisory before deployment. Test patched binaries against both benign and fuzzed RASC samples to confirm the fix and prevent regression.

Detection guidance

Monitor FFmpeg processes for crashes or abnormal termination when processing video files, particularly those with RASC encoding. Log or alert on decode errors involving the RASC decoder or 'dlta' function calls. If possible, use AddressSanitizer or MemorySanitizer during testing to catch heap corruption. In production, implement sandboxing around video decoding (e.g., separate user, container, or process) to contain the impact of a compromised decoder.

Why prioritize this

This vulnerability merits high priority due to its CVSS 3.1 score of 8.6 (HIGH severity), network-accessible attack vector, low complexity, and potential for arbitrary code execution via heap corruption. It requires no authentication or user interaction. Organizations processing video should prioritize patching, especially if they operate media ingestion or transcoding pipelines that accept untrusted input.

Risk score, explained

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H reflects a remotely exploitable flaw with low attack complexity, no privilege requirement, and no user interaction needed. Confidentiality and integrity impacts are rated low (heap corruption may leak or corrupt data, but not directly access arbitrary memory). Availability impact is high because heap corruption commonly causes denial of service. The score of 8.6 reflects the practical risk of code execution via heap exploitation, though the CVSS base metric conservatively caps integrity at 'low.'

Frequently asked questions