← Back to Feed CACHED · 2026-06-23 12:54:37 · CACHE_KEY CVE-2026-8461
CVE-2026-8461 · CWE-787

Heap out-of-bounds write via odd slice_height in FFmpeg MagicYUV decoder

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A boutique codec nobody asked for just became your transcoding fleet's backdoor

MagicYUV is a lossless intermediate codec used mostly in video editing workflows — niche, but FFmpeg ships a decoder for it and that decoder is enabled by default in every standard build. The bug is a classic CWE-787 heap out-of-bounds write: when the slice_height field in a MagicYUV bitstream is odd, the decoder's row-stride math goes negative-or-misaligned and the chroma plane reconstruction loop writes past the allocated plane buffer. Affected range covers FFmpeg n4.4 through n7.1.x and n8.0 pre-fix, plus every distro and SDK that statically links libavcodec (Chromium-derived browsers ship their own fork — check separately).

Vendor's HIGH/8.8 is defensible but slightly optimistic on the user-interaction assumption. The CVSS vector says UI:R, which is true for desktop media players but false for any server-side pipeline that auto-transcodes uploaded video — and that's where FFmpeg lives in the enterprise. We hold the severity at HIGH and trim the score modestly because MagicYUV is rare enough that drive-by content delivery is unlikely, but the server-side transcoder path is fully unattended and that's the realistic blast vector.

"HIGH stands. Obscure codec narrows exposure, but server-side transcoders are the soft underbelly — RCE without user interaction in that path."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Craft a malformed MagicYUV file

Attacker uses a fuzzer-derived template (AFL++, Honggfuzz, or the public ffmpeg-fuzz corpus) to produce an .mkv or raw .huff container wrapping a MagicYUV stream where slice_height is set to an odd value while frame height and bit depth are tuned to push the OOB write into a controllable adjacent heap chunk.
Conditions required:
  • Knowledge of MagicYUV bitstream layout (FFmpeg source is public)
  • Heap grooming primitive via repeated decode calls or large-allocation neighbor
Where this breaks in practice:
  • MagicYUV is niche — most fuzzing corpora deprioritized it until this CVE
  • Modern glibc/jemalloc/mimalloc tcache randomization reduces grooming reliability
Detection/coverage: YARA rules on MAGY FourCC plus odd slice_height field; FFmpeg -err_detect explode will reject some malformed streams
STEP 02

Deliver to a target running affected libavcodec

Two realistic delivery paths: (a) upload to a server-side video pipeline that accepts user content and runs ffmpeg -i for transcoding/thumbnailing, or (b) trick a desktop user into opening the file with VLC/mpv/SMPlayer or any electron app that bundles ffmpeg. Server-side is unattended; desktop requires the user click.
Conditions required:
  • Target accepts uploads or executes media
  • Target's libavcodec build has MagicYUV enabled (default)
Where this breaks in practice:
  • Most upload pipelines whitelist container formats — .huff would be rejected, but .mkv wrapping MagicYUV typically is not
  • Desktop media players are increasingly sandboxed (mpv on Flatpak, VLC on Windows Defender attack-surface reduction)
Detection/coverage: Upload-tier file-type sniffing rarely inspects codec ID inside MKV; SOC will not see this without deep inspection
STEP 03

Trigger the OOB write inside libavcodec

Decoder hits the odd slice_height path, computes a stride that writes attacker-controlled chroma data past the destination buffer, corrupting an adjacent heap chunk. With heap grooming the corrupted target is a vtable, function pointer, or AVCodecContext callback structure.
Conditions required:
  • Target process actually decodes (not just probes) the stream
  • Heap layout permits a useful corruption target
Where this breaks in practice:
  • GCC -D_FORTIFY_SOURCE=3, glibc safe-linking, and Windows CFG/ACG raise the bar but do not eliminate the bug class
  • FFmpeg slice-threading randomizes allocation order, hurting determinism
Detection/coverage: ASan/MSan instrumented builds catch this instantly; production builds will SIGSEGV on failed exploit attempts — watch for crash loops
STEP 04

Pivot from RCE in the decode process

On a transcoding worker the attacker now executes as the ffmpeg child process — typically a constrained service account, sometimes inside a container or seccomp jail. From there: token theft, lateral movement, or — on poorly isolated pipelines — direct access to object storage credentials and the upload queue.
Conditions required:
  • No process isolation beyond OS user
  • Service account has credentials in env or IMDS reach
Where this breaks in practice:
  • Mature pipelines run ffmpeg under gVisor, Firecracker, or per-job containers with no creds — exploit gets you a disposable sandbox
  • Cloud IMDSv2 with hop-limit 1 blocks the easy credential grab
Detection/coverage: EDR on a transcode worker should flag ffmpeg spawning shell/network children — high-signal alert
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed as of 2026-06-23 — no GreyNoise tags, no incident reports tying this CVE to active campaigns
Proof-of-conceptCrash PoC (malformed .mkv sample) circulated in the FFmpeg-security list and on oss-fuzz issue tracker; no public weaponized RCE PoC yet
EPSS0.00346 (≈0.35%, ~70th percentile) — low but non-zero, consistent with a fresh memory-corruption bug awaiting weaponization
KEV statusNot listed by CISA
CVSS vectorAV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the UI:R is misleading: server-side transcoders satisfy UI:N in practice
Affected versionsFFmpeg n4.4 through n7.1.x; n8.0 before the fix commit. Anything statically linking libavcodec in that range, including Handbrake, OBS bundles, and many Electron apps
Fixed versionsFFmpeg n8.0.1, n7.1.2, n6.1.4 LTS; Debian bookworm-security and Ubuntu noble-updates backports landing within the patch cycle
Exposure dataShodan/Censys do not directly fingerprint libavcodec versions; estimated installed base is *millions* across servers and desktops via package dependency graphs
DisclosureReported via Google OSS-Fuzz; coordinated disclosure to the FFmpeg security team
ReporterOSS-Fuzz automated harness with triage by FFmpeg maintainers (Michael Niedermayer et al.)
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.4/10)

HIGH holds because FFmpeg is a near-universal dependency and the realistic exploitation surface is the server-side transcoding pipeline, where UI:R collapses to unattended RCE on infrastructure handling untrusted uploads. The single most decisive factor is the role multiplier on transcoding workers — those hosts process attacker-controlled content by design, so the user-interaction friction the vendor scored against does not apply to the worst-case deployment.

HIGH Bug class and affected version range
MEDIUM Real-world exploitability against hardened heap allocators
LOW Likelihood of in-the-wild weaponization in the next 90 days

Why this verdict

  • Universal dependency: libavcodec is embedded in transcoders, thumbnailers, browsers, media players, and dozens of SaaS upload pipelines — installed base is effectively the whole internet's media plane.
  • UI:R is a fiction on servers: any pipeline that auto-decodes uploads (UGC platforms, e-commerce product video, KYC liveness, CCTV ingest) satisfies the precondition without a human in the loop, neutralizing the vendor's primary friction assumption.
  • Role multiplier — transcoding worker: if a worker is compromised, blast radius typically stops at the sandbox/container layer in mature pipelines but reaches object-storage credentials and the queue in immature ones. Not fleet-scale, not identity-scale → does not floor at CRITICAL.
  • Role multiplier — desktop player: real UI:R, low yield against modern sandboxed players (mpv-Flatpak, VLC-Defender ASR), and MagicYUV is an unfamiliar codec a user is unlikely to receive organically.
  • Friction adjustments: obscure codec (-), no weaponized PoC yet (-), heap hardening on modern targets (-), but offset by zero-auth server path (+) and decoder enabled by default (+) — net: hold at HIGH, trim score from 8.8 to 7.4.

Why not higher?

Not CRITICAL because libavcodec is not a high-value-role component in the canonical sense — it does not run as a domain controller, hypervisor, IdP, or kernel-mode agent, and a successful RCE on a transcoding worker is typically contained to that sandboxed job. No KEV listing, no public weaponized exploit, and the obscurity of MagicYUV means broad opportunistic exploitation is unlikely in the near term.

Why not lower?

Not MEDIUM because the server-side transcoding path is a real, unattended RCE primitive on a component that processes attacker-controlled input by design. Any UGC platform, social network, or media SaaS using vanilla ffmpeg for ingest is exposed without user interaction, and the heap-write primitive is controllable enough that weaponization is a question of *when*, not *if*.

05 · Compensating Control

What to do — in priority order.

  1. Disable the MagicYUV decoder in transcoding pipelines — Rebuild ffmpeg with --disable-decoder=magicyuv or pass -vn / explicit codec allowlist (-c:v h264,hevc,vp9,av1) to reject MagicYUV at the command line. Deploy within 30 days per noisgate mitigation SLA for HIGH; this kills the attack surface without waiting for the package update.
  2. Sandbox the ffmpeg child process — Run transcoding under gVisor, Firecracker, bubblewrap, or a per-job container with no network egress, no IMDS reach, and no mounted secrets. This contains a successful exploit to a disposable jail and is the most durable control against the *next* libavcodec CVE too. Implement within 30 days.
  3. Enforce codec allowlisting at the upload tier — Probe uploaded files with ffprobe -show_streams and reject any that report codec_name=magicyuv before they reach the transcoder. Cheap, fast, and survives container/extension mismatches.
  4. Patch to FFmpeg n8.0.1 / n7.1.2 / n6.1.4 — Remediation — must land within 180 days per noisgate remediation SLA for HIGH. Rebuild any internal images that statically link libavcodec; do not assume apt update covers vendored copies in Electron, OBS bundles, or custom containers.
  5. Inventory libavcodec usage via SBOM scan — Run Syft/Grype or Trivy against all container images and host packages to find vendored copies of FFmpeg ≤ n8.0 / n7.1.1 / n6.1.3. Static-linked binaries will not be caught by OS package managers.
What doesn't work
  • WAF rules — the malicious payload is inside a video container; signature inspection on uploaded blobs is not feasible at line rate.
  • Antivirus on file upload — AV is blind to malformed-decoder triggers; nothing about a valid MKV with an odd slice_height looks malicious to a signature engine.
  • Disabling autoplay in browsers — irrelevant: this is a libavcodec bug, not a <video> element bug. Browsers usually ship their own forked decoders.
  • Network segmentation alone — does not help the upload path that *must* accept untrusted content by design.
  • Trusting the UI:R in the CVSS vector — on server-side pipelines there is no user, and the chain runs unattended.
06 · Verification

Crowdsourced verification payload.

Run on every Linux host or container image that may bundle ffmpeg. Invoke as ./check-cve-2026-8461.sh (no args) on the target. Requires read access to ffmpeg in $PATH plus any vendored copies you pass via FFMPEG_PATHS="/opt/app/bin/ffmpeg /usr/local/bin/ffmpeg". No root required.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2026-8461.sh
# Detect FFmpeg builds vulnerable to MagicYUV heap OOB write (CVE-2026-8461)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u

FIXED_8x="8.0.1"
FIXED_7x="7.1.2"
FIXED_6x="6.1.4"

verdict="PATCHED"
any_found=0

version_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

check_binary() {
  local bin="$1"
  [ -x "$bin" ] || return
  any_found=1
  local ver
  ver=$("$bin" -version 2>/dev/null | head -n1 | awk '{print $3}' | sed 's/^n//;s/-.*//')
  if [ -z "$ver" ]; then
    echo "[?] $bin : could not parse version"
    verdict="UNKNOWN"
    return
  fi
  local major="${ver%%.*}"
  local fixed=""
  case "$major" in
    8) fixed="$FIXED_8x" ;;
    7) fixed="$FIXED_7x" ;;
    6) fixed="$FIXED_6x" ;;
    4|5) echo "[!] $bin : $ver (EOL branch, treat as VULNERABLE)"; verdict="VULNERABLE"; return ;;
    *) echo "[?] $bin : $ver (unknown branch)"; verdict="UNKNOWN"; return ;;
  esac
  if version_ge "$ver" "$fixed"; then
    echo "[+] $bin : $ver  (fixed, >= $fixed)"
  else
    echo "[!] $bin : $ver  (VULNERABLE, needs $fixed)"
    verdict="VULNERABLE"
  fi
  # confirm magicyuv decoder is compiled in
  if "$bin" -hide_banner -decoders 2>/dev/null | grep -q ' magicyuv '; then
    echo "    -> magicyuv decoder is ENABLED"
  else
    echo "    -> magicyuv decoder is disabled (mitigated)"
  fi
}

# default search
for b in $(command -v ffmpeg 2>/dev/null) /usr/bin/ffmpeg /usr/local/bin/ffmpeg /opt/ffmpeg/bin/ffmpeg; do
  [ -n "$b" ] && check_binary "$b"
done

# user-supplied extra paths
for b in ${FFMPEG_PATHS:-}; do
  check_binary "$b"
done

if [ "$any_found" -eq 0 ]; then
  echo "UNKNOWN: no ffmpeg binary found on PATH or in standard locations"
  exit 2
fi

echo "RESULT: $verdict"
case "$verdict" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Treat this as a server-side problem first. Monday morning: inventory every container image and host that bundles libavcodec (use Syft/Grype against your registry), then ship a config change to your transcoding workers that either rebuilds ffmpeg with --disable-decoder=magicyuv or enforces a codec allowlist at the ffprobe upload gate — that is your noisgate mitigation SLA target of ≤30 days for a HIGH verdict. Schedule the actual upgrade to FFmpeg n8.0.1 / n7.1.2 / n6.1.4 (plus distro backports and every vendored copy in Electron apps, OBS, Handbrake, internal SDKs) inside the noisgate remediation SLA of ≤180 days. Desktop fleet can ride the normal package-update train; the urgency is on anything that auto-decodes user-supplied video.

Sources

  1. FFmpeg security advisories
  2. FFmpeg git log — libavcodec/magicyuv
  3. NVD entry (CVE-2026-8461)
  4. MITRE CVE record
  5. Google OSS-Fuzz issue tracker
  6. CWE-787 — Out-of-bounds Write
  7. Debian security tracker — ffmpeg
  8. CISA KEV catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.