The FFmpeg 9.0.2 CVE list is mostly unreachable. Two aren't.

Most of the FFmpeg 9.0.2 CVE entries published on November 9, 2026 need a crafted input file to reach, but a few sit on code paths a working transcoder runs every day, and no 9.0.x point release carries any of the fixes yet.

The November 9 batch splits into two piles

Roughly seventy IDs in the CVE-2026-125xxx range landed on November 9, 2026, every one filed against "FFmpeg through 9.0.2", and the OpenCVE vendor index sorts them by ID and CVSS rather than by reachability. Sorted that way, a fuzzed Huffyuv frame and a bug on the rotation path you run over every upload look alike. The split that matters to a worker that accepts files from strangers:

A warning about the per-CVE pages a scanner alert links: several are machine-generated and wrong in ways that change your triage. One labels CVE-2026-125262 as OS command injection when the record describes a heap buffer overflow in LCEVC enhancement decoding. Read the CVE record, not the summary page wrapped around it.

display_orientation=insert is the path most pipelines actually run

CVE-2026-125269 sits on a common option: h264_metadata with display_orientation=insert. You run it when a phone upload arrives sideways and you want the rotation written into the stream without re-encoding. The bug is in the bitstream framework underneath: cbs_sei_delete_message() leaves a stale extension_data pointer behind, and ff_cbs_sei_add_message() reuses it. Inserting a display orientation message over a file that already carries one is the delete-then-add sequence that reaches the free.

The code path is only in your process if you pass that filter option. Given that you do, the uploaded file decides whether the sequence fires, and the uploaded file is not yours. A pipeline that normalizes rotation on user video is reachable; a pipeline that re-encodes everything through -vf transpose or lets the scaler handle it is not.

Why the three leaks hurt a worker that transcodes uploads all day

A memory leak CVE looks harmless next to a double free, and for a one-shot CLI run it mostly is: the process exits and the kernel reclaims everything. A worker that runs for weeks behaves differently. CVE-2026-125200 leaks one RPU allocation per encoded frame because libx265_encode_frame() never frees the payload ff_dovi_rpu_generate() hands it, which is 18,000 leaked allocations in a ten minute 30 fps encode, every encode, forever. CVE-2026-125252 leaks VA parameter and slice buffers on every frame where later slices fail to parse, so one slightly damaged upload leaks for its entire duration rather than once.

What you see downstream is not an error. The container crosses its memory limit, the OOM killer takes it, and the orchestration above it reports a timeout or a disappeared node. That failure shape is the same class of problem described in why your transcode job failed and what to do in the poll loop, except the job never gets far enough to report anything. If your render box has been restarting on a schedule that someone added "to keep it healthy," this is a plausible cause.

Check your build before you patch anything

Three commands cut the seventy-item list down to the handful your binary can reach.

Compiled in is not the same as reached. Most distro builds ship VAAPI and VDPAU support even on a cloud VM with no GPU, and those paths only run when you ask for them with -hwaccel. A CPU-only worker that never passes a hwaccel flag does not reach CVE-2026-125252, CVE-2026-125242 or CVE-2026-125265 regardless of what the scanner says about the package.

For the crafted-file pile, narrow at runtime. FFmpeg's codecs documentation covers -codec_whitelist and --disable-decoder=NAME at configure time:

ffmpeg -hide_banner \
  -format_whitelist mov,mp4,m4a \
  -codec_whitelist h264,hevc,aac \
  -i upload.mp4 -c:v libx264 -c:a aac out.mp4

That one line removes roughly sixty of the November entries from your exposure, because the decoders they live in can no longer be selected. It does nothing for CVE-2026-125200 or CVE-2026-125269, which live in the encoder and the bitstream filter rather than in decoder selection. Whitelisting at ingest is the same move as the one in the FFmpeg Brotli CVE has no patch, block it at ingest instead: you cannot patch what you refuse to parse.

What each way out costs you this month

There is no 9.0.3. FFmpeg's own security page lists only the older CVEs fixed in 9.0, and Ubuntu's tracker shows the November batch as needs triage with no fixed package across every supported release, so apt upgrade resolves nothing. That leaves four routes with different bills.

One more option is to stop being the party that patches. FFmpeg Micro runs the encoders, the GPU paths and the bitstream filters on managed infrastructure, so this batch, the November 1 memory-disclosure batch and whatever lands in December are our upgrade to do, not yours. The transcode you were running locally becomes one call:

curl -X POST https://api.ffmpeg-micro.com/v1/transcodes \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inputs":[{"url":"gs://your-bucket/upload.mp4"}],
       "outputFormat":"mp4",
       "preset":{"quality":"medium","resolution":"1080p"}}'

Billing is on the duration of the video you send, metered per second with no rounding up to a minute, and failed jobs are never billed. One token buys ten seconds of input. A new account gets 200 tokens, about 33 minutes of video, with no card. Top-ups are 500 tokens for $5 on any plan including Free, and Starter is $19.99 a month for 2,500 tokens. That is the whole comparison against an afternoon of rebuilding, repeated monthly. The same math applies to the FFmpeg layer in your application image, which is the subject of your PHP Docker image has an FFmpeg layer, who patches it.

When keeping your own build is still the right call

Self-hosting wins in a few situations. If you decode at volume on NVIDIA hardware you already bought, the nvdec path is the reason you bought it, and carrying patches is cheaper than giving up the GPU. If a contract or an air-gapped network means source files cannot leave your infrastructure, the decision is already made. And if your inputs include formats outside MP4, MOV, WebM and AVI, you will keep something local no matter what else you move.

The honest cost in all three cases is the monthly triage: read the batch, check your build, decide what to carry. That is an hour a month that nobody budgets for and everybody spends.

FAQ about the FFmpeg 9.0.2 CVEs

Is there an FFmpeg 9.0.3 that fixes the November 9 CVEs?

No FFmpeg 9.0.3 exists as of November 13, 2026. FFmpeg's security page lists only the CVEs fixed in 9.0 itself, and the November 9 batch is filed against "FFmpeg through 9.0.2" with fixes living in master and in individual distro patches.

Can I patch these by running apt upgrade?

Running apt upgrade does not patch the November 9 FFmpeg CVEs on any supported Ubuntu release. The Ubuntu tracker shows the batch as needs triage with no fixed package from 16.04 through 26.10, so the version you get after upgrading is the same vulnerable 9.0.2 build your scanner flagged.

Does -codec_whitelist actually reduce exposure to this batch?

Restricting decoders with -codec_whitelist h264,hevc,aac removes roughly sixty of the November entries from reach, because the obscure decoders they live in can no longer be selected for your input. It does not cover CVE-2026-125200 in the libx265 encoder or CVE-2026-125269 in the h264_metadata bitstream filter, which run after decoder selection.

Why does a memory leak CVE matter if all my jobs complete successfully?

A memory leak in the encoder or decoder matters because long-running workers never exit, so leaked allocations accumulate across thousands of jobs instead of being reclaimed at process end. The worker is OOM-killed hours or days later, which surfaces as a dead container rather than a failed job.

Does moving to the FFmpeg 9.1 branch fix these CVEs?

The 9.1 branch is a feature branch, not a security release for this batch, and the November CVEs were filed against "through 9.0.2" rather than evaluated against 9.1. Moving there also brings the rewritten AAC encoder that missed 9.0, so -c:a aac output changes across the upgrade and your audio needs re-testing.

Whichever pile your build lands in, the triage repeats in December. A free account comes with 200 tokens and no card, and the dashboard walks you through the quickstart: a temporary API key, a presigned upload, a transcode, the poll loop and the download, with the request and response shown at each step. Sign up free and your video step runs with no servers to run and no FFmpeg to install, called from your own code, from n8n, Make and Zapier, or from your AI agents.