CVE-2026-58049: 
Ffmpeg vulnerability analysis and mitigation

CVE-2026-58049 is a heap out-of-bounds write vulnerability in FFmpeg's RASC video decoder (decode_dlta in libavcodec/rasc.c) that allows an unauthenticated remote attacker to trigger memory corruption via a crafted media stream. The flaw affects FFmpeg upstream master up to and including commit bcd2c69e087a09b07cf45c6bd2428ee1ccb2925c (verified as of 2026-06-26), as well as Red Hat AI Inference Server, Red Hat Enterprise Linux AI (RHEL AI) 3, and Red Hat OpenShift AI (RHOAI). It was published on June 28, 2026, with a CVSS v3.1 base score of 8.6 (High) and a CVSS v4.0 base score of 8.8 (High) (Github Advisory, Red Hat Bugzilla).

The root cause (CWE-787: Out-of-bounds Write) lies in decode_dlta(), which tracks a byte cursor cx inside a DLTA region whose width is validated in pixel units (w) rather than byte units (w * s->bpp). For PAL8 frames where s->bpp = 1, run types 4, 7, 12, and 13 perform 32-bit reads (AV_RL32) and writes (AV_WL32) at the current cursor position before the NEXT_LINE row-boundary check fires, allowing the 4-byte operation to cross the row allocation boundary. Specifically, with x = 63, w = 1, h = 1 on a 64-pixel row, the 32-bit store at b2 + cx writes one byte into the final row byte and three bytes into adjacent heap memory. A public PoC (ffmpeg_rasc_dlta_calc_poc.c) demonstrates callback pointer hijacking via this overwrite, confirmed by ASAN on the affected commit (PoC Repository, FFmpeg Source).

Successful exploitation results in a bitstream-controlled heap write of up to three bytes past a frame row allocation, enabling memory corruption that can lead to arbitrary code execution or process crash. The primary availability impact is high (process termination or hijack), with low confidentiality and integrity impacts due to the limited but attacker-controlled write primitive. Systems that automatically decode untrusted media — including media servers, AI inference pipelines using FFmpeg (e.g., Red Hat OpenShift AI), and desktop applications — are at risk of remote code execution without any user interaction (Github Advisory, Red Hat Bugzilla).

1. Craft a malicious RASC media stream: Build an AVI/RIFF container with the RASC FourCC. Include an INIT/FINT chunk specifying width=64, height=1, format=8 (PAL8), and a valid 1024-byte palette. Follow with a DLTA chunk specifying x=63, y=0, w=1, h=1, compression=0, and run type 7 with a 32-bit fill value computed as ((target_address & 0x00ffffff) << 8) | 0x41.
2. Deliver the stream to the target: Provide the crafted file or stream to any system invoking libavcodec to decode RASC content — this can be via file upload, network stream, or API call to a media processing service.
3. Trigger decoding: When FFmpeg processes the DLTA chunk, decode_dlta() sets b2 = frame2->data[0] + 63 (last byte of the 64-byte PAL8 row). Run type 7 executes AV_WL32(b2 + cx, fill), writing 4 bytes starting at offset 63 — one byte in-bounds and three bytes overwriting adjacent heap memory.
4. Overwrite a heap function pointer: By controlling the heap layout (e.g., via a custom get_buffer2 callback that places a function pointer immediately after the 64-byte frame plane), the three out-of-bounds bytes overwrite the low three bytes of the adjacent callback pointer, redirecting it to attacker-controlled code.
5. Achieve code execution: After decoding completes, the PoC invokes the now-hijacked callback pointer, executing arbitrary code (demonstrated as launching Calculator). In a real attack, this would be replaced with a reverse shell or other payload (PoC Repository, FFmpeg Source).

• File System: Presence of /tmp/ffmpeg_rasc_exec_demo marker file, which the PoC callback writes upon successful exploitation; unexpected binaries or scripts dropped in world-writable directories by the FFmpeg process.
• Process: Unusual child processes spawned by an FFmpeg or media-decoding process (e.g., calc, gnome-calculator, bash, sh, curl, wget, python); FFmpeg process terminating abnormally with a segmentation fault or SIGABRT.
• Logs: ASAN/sanitizer output referencing heap-buffer-overflow in decode_dlta at libavcodec/rasc.c:421; application crash logs showing READ of size 4 or WRITE of size 4 at addresses 2+ bytes past a 64-byte heap region.
• Network: Inbound delivery of AVI/RIFF files or streams containing the RASC FourCC (52415343) to media processing endpoints; outbound connections from media-processing services to unexpected external hosts following media decode operations (PoC Repository).

Update FFmpeg to a commit after bcd2c69e087a09b07cf45c6bd2428ee1ccb2925c once an official patched release is available; the fix requires adding a cx + 4 <= w * s->bpp guard before every 32-bit read/write in DLTA run types 4, 7, 12, and 13. As an immediate workaround, avoid decoding untrusted media files using the RASC codec (AV_CODEC_ID_RASC), and restrict or disable RASC decoder support by building FFmpeg without --enable-decoder=rasc. Red Hat has acknowledged impact on Red Hat AI Inference Server, RHEL AI 3, and Red Hat OpenShift AI — monitor Red Hat advisories for patched package releases (Github Advisory, Red Hat Bugzilla).

The Hacker Wire published a dedicated technical write-up on the vulnerability shortly after disclosure (The Hacker Wire). Infosecurity Magazine covered the broader exploitarium repository and its researcher-published exploits, including this CVE (Infosecurity Magazine). The Yocto Project security mailing list flagged the issue for embedded Linux maintainers, and community discussion appeared on Bluesky. The availability of a working calculator PoC drew notable attention from the security research community given the low-complexity, no-authentication-required attack surface.