FFmpeg CVE-2026-96611: is your self-hosted build patched?

The advisory says "FFmpeg before 9.0" and stops there. That tells you nothing useful, because you probably don't know which FFmpeg your pipeline runs, and the version number on the package isn't the answer anyway. The binary your worker executes is the only version that counts.

Quick answer: CVE-2026-96611 is a signed integer overflow in FFmpeg's MOV/HEIF parser that affects FFmpeg releases before 9.0, so if your pipeline ingests user-uploaded HEIC/HEIF photos or MOV files, check the version inside the container that runs the job with docker exec <container> ffmpeg -version, then move to FFmpeg 9.0 or later, or to a distro package carrying the backport (Debian trixie's 7:7.1.5-0+deb13u1 and forky's 7:8.1.2-1 are both fixed). If you'd rather not own FFmpeg's patch cycle, send the job to a hosted API like FFmpeg Micro in one call, where the version is somebody else's maintenance window.

Conventional wisdom on a CVE like this is "check the version, compare it to the fixed version, upgrade if you're below it." That works for most software. It fails here, in both directions: Debian ships a patched 7.1.5, which reads as vulnerable by version number, and Ubuntu ships an unevaluated 7.1.1 that reads the same way but isn't fixed. Version number isn't the signal. Provenance is.

How to check the FFmpeg version your pipeline actually uses

The FFmpeg that matters is the binary your job process executes, almost never the one on your laptop or Docker host. Run the check inside the container that does the work:

# the container running the job, not the host
docker exec -it n8n-worker ffmpeg -version | head -2

# where did that binary come from?
docker exec -it n8n-worker sh -c 'which -a ffmpeg'

# Debian/Ubuntu base: the exact package revision, which is what the trackers key on
docker exec -it n8n-worker dpkg -s ffmpeg | grep -E '^(Package|Version)'

# Alpine base
docker exec -it n8n-worker apk info -v ffmpeg

Two outputs, two different answers. ffmpeg -version gives you the upstream version string, which is what you need for a static build. dpkg -s gives you the distro revision (7:7.1.5-0+deb13u1), which is the only thing that tells you whether a backport landed. If you run n8n 2.x with external task runners, the FFmpeg binary usually lives in the n8nio/runners image, not the main n8n container, so check there too.

For a git or static build, the first line of ffmpeg -version ends in a commit hash (ffmpeg version N-121847-g059eb2e853). The fix is commit 059eb2e853c1f62b8df1b73be9318061a7a21b0b, referenced from PR #23455, so you can check it against your build's tree instead of guessing from the release number.

Does my 7.1.5 or 8.1.2 package mean I'm patched?

A package numbered below 9.0 can still carry the fix, and the distro tracker is the only place that says so. The Debian security tracker records this one as backported into trixie at 7:7.1.5-0+deb13u1 and forky at 7:8.1.2-1. Bookworm sits at 7:5.1.9-0+deb12u1 with no fix available.

Ubuntu's page for the CVE lists every supported release, xenial through 26.04 resolute, as "Needs evaluation." That's the most common self-host base image, with no fix and no timeline. A widely-cited September roundup on DEV also states an 8.x backport "is not confirmed," which the Debian tracker now contradicts. Check your own distro's tracker and nothing else.

Upstream, this is a branch choice, not an upgrade. FFmpeg's download page currently lists 9.0.2 "Lei" (Sep 18, 2026), 8.1.3 "Hoare" (Sep 21, 2026), 8.0.3, 7.1.5 "Péter" LTS, 6.1.6, 5.1.10 "Riemann" LTS and 4.4.8. The OSV record flags branches n0. through n8. as affected with the fix in 9.0, so don't assume 8.1.3 carries it just because it shipped three days after 9.0.2.

Which of my workflows are actually exposed

The vulnerable code path is mov_read_ispe() feeding read_image_grid(), the tiled-HEIF branch. Width and height values come out of the file's ispe box as uint32_t, get stored into signed int fields with no bounds check, and the grid accumulation wraps to a small positive number that passes the later validity checks. Tiled HEIC is what iPhones produce by default, so that grid path is what an iPhone photo is.

So the exposed pipelines are the intake ones. If a stranger can upload a photo or a phone video and your worker runs ffmpeg or ffprobe against it, you're parsing attacker-controlled input. In practice that means product-photo intake for e-commerce listings, UGC collection forms, anything accepting camera-roll uploads from a mobile app, and the .MOV half of every "user sends a clip, we transcode it" workflow. Plain MP4 from a known encoder doesn't touch the HEIF grid code. The HEIC/HEIF still-image path and MOV containers do.

The CVSS vector reads AV:L, local attack vector, which looks reassuring. But "local" in CVSS describes the attacker reaching the vulnerable process, and in an upload pipeline the file crosses the network while the parse happens locally on your worker. Treat it as untrusted-file handling, not remote network exposure.

Is this a tonight problem or a this-sprint problem

Patching this CVE is a sprint item, not a tonight item. The record is CVSS 6.9 medium, vector CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L, classed CWE-190, published September 23, 2026. Attack complexity is high. There's no public proof-of-concept and no confirmed exploit code, it isn't in the CISA Known Exploited Vulnerabilities catalog, and EPSS puts 30-day exploitation probability at 0.11%.

That matters for how you patch, because the rushed version of this fix is worse than the bug. Jumping a production worker from 8.x to 9.x to close a 6.9 with no PoC can take down every job that still passes -vsync, trading a parse bug for an outage. Plan the move, don't panic it.

How to re-pin an n8n worker image without breaking existing jobs

Rebuilding the image is the actual work, and the order matters more than the Dockerfile. The two verified routes into the official n8n image land on different FFmpeg versions, measured against n8nio/n8n:2.39.8 on 2026-09-20: restoring apk into the distroless base yields FFmpeg 8.1.2 at roughly +150 MB, while copying the mwader/static-ffmpeg build yields 9.0.1 at roughly +340 MB.

If you're on FFmpeg 9.0+ now, also check your HTTPS sources. FFmpeg 9 flipped tls_verify to 1 by default, which surfaces as certificate verify failed on remote inputs that used to work.

Common pitfalls when checking and patching

Bad version checks usually come from checking the wrong thing. Running ffmpeg -version on the Docker host tells you about the host, not the worker. apt list ffmpeg shows what's in the repo, not what's installed, so use dpkg -s ffmpeg. A static build's upstream version string says nothing about distro backports, and a distro revision says nothing about upstream commits, so match the check to the binary's origin.

The other cluster is scope. Your n8n container, your task-runner image, your Lambda layer, and any sidecar running ffprobe for metadata are four separate FFmpeg installs with four separate versions. Thumbnailers and metadata extractors get forgotten, and ffprobe parses the same ispe box the demuxer does.

The maintenance question this raises

Count the version-level FFmpeg events in the last quarter: scale_npp deleted, -vsync removed, TLS verification flipped on by default, and now a parser CVE where the fix is only unambiguously present in a release that breaks your flags. Self-hosters carry debt they can't clear. n8n issue #38532, filed September 12, 2026, reports the published n8nio/n8n:2.39.4 image shipping 17 fixable CVEs, one critical, with fixes already available upstream at build time.

That's the real tradeoff: running your own FFmpeg means you own the parser's attack surface, the branch choice, and the rebuild window, every time. Sending the job to FFmpeg Micro means you own neither, because a hosted API is a version you never have to patch. The cost is less control over the exact build and flags you run. For an intake pipeline accepting stranger-uploaded HEIC, most teams find that trade obvious; for a tuned GPU encoding farm, it isn't.

FAQ

Does accepting MP4 uploads expose me to CVE-2026-96611?

Plain MP4 from a normal encoder doesn't reach the vulnerable code. CVE-2026-96611 lives in FFmpeg's tiled-HEIF grid handling via the ispe box, so the exposed inputs are HEIC/HEIF stills and MOV containers carrying that structure. The practical risk line is whether an untrusted party chooses the file, not which extension you accept.

Is FFmpeg 8.1.3 patched against CVE-2026-96611?

The upstream record for CVE-2026-96611 lists branches n0. through n8. as affected and names 9.0 as the fixed release, so don't assume 8.1.3 is patched on the version number alone. Verify that commit 059eb2e853c1f62b8df1b73be9318061a7a21b0b is in your build, or use a distro package whose tracker records the backport.

Ubuntu says "Needs evaluation" for every release. What do I do now?

While Ubuntu's status for CVE-2026-96611 stays unevaluated, your options are to switch the worker's base to Debian trixie (patched at 7:7.1.5-0+deb13u1), pin a static FFmpeg 9.0.x build into the image, or stop parsing untrusted HEIC/HEIF in that worker. Rejecting HEIC at the upload boundary and converting it elsewhere is a legitimate interim control if the rebuild has to wait.

How do I check the FFmpeg version inside a Docker container?

Run docker exec <container> ffmpeg -version for the upstream version string and docker exec <container> dpkg -s ffmpeg (or apk info -v ffmpeg on Alpine) for the distro package revision. Check every container that touches media, including task-runner and thumbnailer images, because each one has its own FFmpeg.

Can I avoid FFmpeg version maintenance entirely?

Offloading the media step to a hosted FFmpeg API removes the binary from your infrastructure, so CVE response, branch choice, and image rebuilds stop being your work. You give up control of the exact build, and you take on a network dependency for the job.

If the rebuild math in step 2 looks worse than the CVE, that's a reasonable signal to move the parse off your own workers. You can run the same transcode, caption, or thumbnail job as one API call with no FFmpeg to install and no servers to run, on a free tier: sign up free.