JFrog Security Research disclosed CVE-2026-8461 — nicknamed PixelSmash — a heap out-of-bounds write in FFmpeg’s MagicYUV decoder that escalates from a routine crash to reliable remote code execution using a single crafted video file under 50 kilobytes. Because FFmpeg’s MagicYUV decoder ships enabled by default in upstream builds and is silently pulled in by hundreds of downstream projects, the bug reaches far past desktop media players into the server infrastructure that ingests and transcodes user-uploaded video: Jellyfin, Emby, Nextcloud, Immich, PhotoPrism, and OBS Studio all confirmed affected, with full RCE demonstrated against Jellyfin and Nextcloud.

What Happened

FFmpeg’s libavcodec MagicYUV decoder reads an attacker-controlled slice_height value directly from the bitstream. The decoder and the frame allocator compute the chroma-plane height differently: when slice_height is odd, the decoder’s ceiling-rounded shift produces one extra chroma row per slice that the allocator never accounted for. A file with multiple slices accumulates those extra rows into an out-of-bounds heap write — JFrog’s PoC writes up to 640 bytes past the allocated buffer, enough to corrupt adjacent heap metadata, function pointers, and, on unprotected builds, redirect execution.

The trigger file is a MagicYUV-encoded video wrapped in an AVI, MKV, or MOV container — MP4 isn’t exploitable because MagicYUV isn’t registered in the MP4 codec table. JFrog demonstrated two real-world RCE chains: uploading the crafted AVI to a Jellyfin server, where it’s picked up automatically during a routine library scan, and uploading it as a video attachment to Nextcloud, where the preview-generation pipeline invokes FFmpeg on unprocessed input. Neither requires any user interaction beyond the initial upload. Reliable RCE depends on ASLR being disabled or chained with a separate info-leak; without that, exploitation still reliably crashes the decoding worker, giving attackers a trivial DoS against any pipeline that auto-transcodes uploads.

Crashes were independently confirmed against Kodi, mpv, ffmpegthumbnailer, PhotoPrism, and OBS Studio, meaning the blast radius extends to any self-hosted media stack, NAS appliance, or CI pipeline that shells out to FFmpeg or an FFmpeg-linked library to thumbnail, transcode, or preview video from untrusted sources.

Technical Details

  • CVE-2026-8461 — heap out-of-bounds write in FFmpeg’s MagicYUV decoder (libavcodec/magicyuv.c), CVSS 3.1 8.8 (High)
  • Root cause: mismatched chroma-plane height calculation between the frame allocator and decoder when slice_height is odd
  • Affected: FFmpeg prior to 8.1.2 — any downstream project statically or dynamically linking a vulnerable libavcodec build, including forks and vendored copies
  • Fixed in: FFmpeg 8.1.2 (“Hoare”), released June 17, 2026, which adds validation rejecting slice heights not aligned to chroma vertical subsampling
  • Attack surface: any server-side process that auto-decodes untrusted video — media servers, cloud photo/video backends, thumbnailing services, streaming ingest, CI artifact previews
  • Discovery timeline: reported to the FFmpeg security team by JFrog on May 13, 2026; patched June 17; publicly disclosed with technical write-up on June 23

Impact

This is a supply-chain-shaped bug: almost nobody runs “FFmpeg” directly, they run something that vendors it. Self-hosted media servers (Jellyfin, Emby), photo/video backup platforms (Immich, PhotoPrism), collaboration suites (Nextcloud), and streaming/recording tools (OBS Studio) all inherited the flaw through their FFmpeg dependency without any code change of their own. Any deployment that automatically scans, thumbnails, or transcodes user-supplied video — which is the default behavior for most of these products — is remotely reachable by an unauthenticated or low-privilege uploader. For hosted or multi-tenant instances (shared Nextcloud deployments, Jellyfin instances with open registration, photo-backup services), this is a pre-auth or low-auth RCE path into the host running the media pipeline.

Mitigation

  • Upgrade to FFmpeg 8.1.2 or later, or apply the upstream patch to libavcodec/magicyuv.c if vendoring a fork
  • Update dependent applications to versions that bundle the patched FFmpeg: Jellyfin has already shipped an updated bundled build; check Emby, Nextcloud’s previewgenerator dependencies, Immich, and PhotoPrism for updated container images
  • Where an immediate update isn’t possible, disable automatic thumbnail/preview generation for AVI, MKV, and MOV uploads, or run transcoding workers in a sandboxed, non-privileged container with ASLR enforced and no network egress
  • PhotoPrism has indicated it is adding a file-format blocklist as an interim mitigation — treat this as a stopgap, not a fix
  • Audit any internal tooling (CI artifact previews, DAM systems, ingest pipelines) that shells out to ffmpeg/ffprobe against user-uploaded files; these are just as exposed as the named consumer products

References: JFrog Security Research write-up, BleepingComputer coverage, SecurityWeek report.