CVE-2026-8461

What it actually does

An out-of-bounds write in FFmpeg's libavcodec MagicYUV decoder (libavcodec/magicyuv.c) corrupts memory while decoding a crafted MagicYUV bitstream. The result is typically process crash (denial of service); because the write is attacker-influenced, it can in some configurations escalate to remote code execution in the decoding process. Network-reachable services that decode untrusted media inherit the same memory-corruption risk after a single user-driven open or automatic transcode. Confidentiality, integrity, and availability of the host process are all at risk (CVSS 8.8, AV:N/AC:L/PR:N/UI:R).

Why it matters to the business

Any product that embeds FFmpeg to play, transcode, thumbnail, or inspect video can be crashed or, in worse cases, fully compromised when staff or customers open a malicious MagicYUV file. Impact spans media platforms, conferencing and surveillance pipelines, content-moderation workers, and desktop players. FFmpeg is ubiquitous, so exposure is broad even without a published dependent count. The issue is 103 days old, is not on CISA KEV, is not tied to ransomware, has no public exploit (maturity None), and EPSS has fallen from 0.0157 to 0.0103 (−34%) over 30 days—so mass exploitation is not indicated, but the CVSS 8.8 user-assisted RCE rating still warrants patching of internet-facing ingest and user-facing players.

How an attack unfolds

An attacker prepares a MagicYUV-encoded media file that triggers the out-of-bounds write when libavcodec's MagicYUV decoder parses it. The file is delivered as a download, email/chat attachment, web stream, or upload to a transcode/thumbnail service. The victim (or an automated worker) opens or converts the file with FFmpeg, ffplay, or any application linked to a vulnerable libavcodec. No privileges are required beyond the ability to supply media; user interaction is required for interactive players (CVSS UI:R), while headless ingest may decode automatically. Successful triggering crashes the decoder process or, if memory is arranged favorably, executes attacker-controlled code in that process. No named threat actors or campaigns are associated with this CVE, and no public exploit is reported.

How to fix it

Upgrade FFmpeg to 8.1.2 or later, which contains the MagicYUV decoder fix; rebuild and redeploy every application, container, and appliance that statically or dynamically links libavcodec. If an immediate upgrade is impossible, disable MagicYUV decoding (exclude the decoder at build time or block MAGY/MagicYUV inputs at the ingest boundary) and do not process untrusted media with vulnerable binaries. Prefer vendor-supplied FFmpeg packages that have backported the 8.1.2 magicyuv.c fix rather than compiling from unverified snapshots. After upgrade, restart long-running transcode, thumbnail, and media-proxy services so they load the patched library.

How to confirm the fix worked

Confirm installed FFmpeg/libavcodec reports 8.1.2 or newer (ffmpeg -version, package manager, or linked libavcodec SONAME/changelog). Verify magicyuv.c in the deployed source or vendor advisory includes the vendor fix, and that runtime processes (players, workers, containers) were restarted after the library update. Spot-check that MagicYUV is either decoded by the patched library or rejected at the boundary. Do not use attacker-crafted files to 'prove' the bug; use version and build evidence plus processing of benign MagicYUV samples only. Inventory downstream products that vendor FFmpeg and confirm their fixed-version advisories.

Typical attack path

1. Craft or obtain a MagicYUV (MAGY) bitstream that exercises the vulnerable decoder path in libavcodec
2. Deliver the file or stream via download, message attachment, website, or untrusted upload to a media pipeline
3. Wait for a user or automated FFmpeg/libavcodec consumer to decode the stream
4. Trigger the out-of-bounds write during MagicYUV decode, causing crash or code execution in the decoder process
5. If code execution is achieved, abuse the privileges of the FFmpeg-based process (playback, transcode worker, or plugin) for further impact

How to detect it

Public exploit maturity is None and no threat actors are reported, so confirmed in-the-wild use is unlikely but not impossible. Hunt for abnormal crashes of ffmpeg, ffplay, ffprobe, or host processes that load libavcodec shortly after ingest or playback of MagicYUV/MAGY content. Review application, container, and syslog for decoder abort, segfault, or sanitizer reports whose stack traces include magicyuv or libavcodec MagicYUV functions. On endpoints, inspect crash dumps and WER/core files for those modules after users opened recently downloaded videos. On media pipelines, correlate worker restarts, OOM/segfault exits, and failed jobs with MAGY inputs. Network telemetry is weak (no unique C2); focus on host crashes and media-ingest logs rather than signatures of a known payload.

• magicyuv
• libavcodec/magicyuv
• MAGY
• MagicYUV
• ffmpeg
• ffplay
• ffprobe
• libavcodec

What your security team should do

• Patch or rebuild all FFmpeg/libavcodec consumers to 8.1.2+ on a risk-based schedule: internet-facing ingest and user-facing players first
• Inventory binaries, containers, and appliances that ship libavcodec (players, CMSs, transcoders, surveillance, conferencing) including static links
• Until patched, block or sandbox MagicYUV/MAGY inputs and isolate media workers from sensitive credentials and lateral-movement paths
• Treat this as high-severity memory corruption (CVSS 8.8) but not emergency-KEV: exploit maturity is None, EPSS is low and declining, no ransomware/KEV listing
• Subscribe to FFmpeg and downstream vendor advisories for backports and confirm workers were restarted onto the patched library