CVE-2026-58049: FFmpeg RASC Buffer Overflow Vulnerability

CVE-2026-58049 Overview

CVE-2026-58049 is an out-of-bounds write vulnerability in FFmpeg's RASC video decoder, specifically in the decode_dlta function within libavcodec/rasc.c. The decoder performs 32-bit reads and writes at the row cursor before the NEXT_LINE row-boundary check. It also validates the DLTA region in pixel units instead of byte units. A DLTA run on a PAL8 frame can therefore access several bytes past the row allocation. A crafted media stream using the RASC FourCC triggers a bitstream-controlled heap out-of-bounds write and an adjacent out-of-bounds read, leading to memory corruption. The flaw is tracked under [CWE-787] (Out-of-Bounds Write).

Critical Impact
A remote attacker can deliver a malicious RASC-encoded media stream to any application linked against libavcodec and cause heap memory corruption, enabling potential code execution or process crash.

Affected Products

FFmpeg libavcodec — RASC decoder (libavcodec/rasc.c)
Downstream applications and distributions bundling vulnerable FFmpeg builds
Red Hat products tracking this issue via Red Hat CVE Details

Discovery Timeline

2026-06-28 - CVE-2026-58049 published to NVD
2026-06-30 - Last updated in NVD database

Technical Details for CVE-2026-58049

Vulnerability Analysis

The RASC decoder handles delta-encoded frames through the decode_dlta routine in libavcodec/rasc.c. The function copies pixel runs into a destination buffer while advancing a row cursor. The decoder writes 32 bits at a time before checking whether the cursor has crossed the row boundary defined by NEXT_LINE. This ordering allows writes that extend past the end of the current row into unrelated heap memory.

The validation logic compounds the problem. The decoder measures the DLTA region against the frame dimensions in pixel units rather than byte units. On a PAL8 frame, where each pixel occupies one byte, a run length that appears valid in pixels can still overflow the byte-sized row allocation by several bytes. Attackers control the run length and starting position through the bitstream, giving them precise influence over the location and size of the overflow.

The result is a bitstream-controlled heap out-of-bounds write paired with an adjacent out-of-bounds read. Both primitives operate on data the attacker supplies inside the RASC container.

Root Cause

The root cause is an ordering and unit-mismatch defect. decode_dlta writes before checking NEXT_LINE, and it validates region size in pixels instead of bytes. See the FFmpeg source for the vulnerable logic.

Attack Vector

An attacker crafts a media file or stream using the RASC FourCC. Any process that decodes the stream through libavcodec — including media players, transcoders, thumbnailers, and web services — reaches the vulnerable code path without user interaction beyond opening or processing the file. A proof-of-concept is available in the exploitarium PoC repository. Technical detail is documented in the VulnCheck Security Advisory.

Detection Methods for CVE-2026-58049

Indicators of Compromise

Unexpected crashes, SIGSEGV, or heap corruption aborts in processes linked against libavcodec when handling media files
Media files or streams carrying the RASC FourCC from untrusted sources
AddressSanitizer or Valgrind reports flagging heap-buffer-overflow inside decode_dlta or rasc.c
Anomalous child process behavior from media pipelines such as ffmpeg, ffprobe, or transcoder workers

Detection Strategies

Inventory all software linked against FFmpeg libavcodec and identify versions containing the unpatched rasc.c
Deploy file-scanning rules that identify RASC FourCC signatures in media uploaded to web-facing services
Enable compiler hardening (AddressSanitizer, -fstack-protector-strong, glibc heap checks) in test environments to surface exploitation attempts
Correlate media-processing service crashes with recent file uploads in SIEM telemetry

Monitoring Recommendations

Monitor exit codes and crash dumps from ffmpeg, ffprobe, and any daemon that invokes libavcodec
Alert on repeated crashes from the same user, tenant, or upload source in media-processing pipelines
Track outbound network activity from decoding workers, which could indicate successful code execution
Log and review media MIME types and container FourCC values processed by public-facing services

How to Mitigate CVE-2026-58049

Immediate Actions Required

Update FFmpeg to a fixed release once vendors publish patched builds; monitor the Red Hat advisory and the Red Hat CSAF VEX document for status
Rebuild and redeploy any statically linked applications after upgrading libavcodec
Restrict untrusted media uploads to isolated, resource-limited sandboxes until patches are applied
Reject or strip files advertising the RASC FourCC at the application boundary where feasible

Patch Information

A fix is being coordinated upstream in the FFmpeg repository and tracked by distributions through the Red Hat Bug Report. Apply the vendor-supplied package update for your Linux distribution or rebuild from patched FFmpeg sources once available.

Workarounds

Disable the RASC decoder at build time by configuring FFmpeg with --disable-decoder=rasc
Block RASC-containing files at ingress filters, web application firewalls, or media proxies
Run media-processing workloads under seccomp, AppArmor, or SELinux profiles that block execve and outbound sockets
Isolate transcoding services in ephemeral containers with no persistent storage or credentials

bash

# Rebuild FFmpeg without the vulnerable RASC decoder
./configure --disable-decoder=rasc
make && make install

# Verify the decoder is no longer registered
ffmpeg -decoders | grep -i rasc