Skip to content

Bump FFmpeg to 8.1.2 on 5.x (CVE-2026-8461) - #1255

Open
MDSALMANSHAMS wants to merge 4 commits into
opencv:5.xfrom
MDSALMANSHAMS:fix-5x-ffmpeg-812-cve
Open

Bump FFmpeg to 8.1.2 on 5.x (CVE-2026-8461)#1255
MDSALMANSHAMS wants to merge 4 commits into
opencv:5.xfrom
MDSALMANSHAMS:fix-5x-ffmpeg-812-cve

Conversation

@MDSALMANSHAMS

Copy link
Copy Markdown
Contributor

Summary

Bumps FFmpeg from 8.1.1 to 8.1.2 on the 5.x branch to fix CVE-2026-8461 (out-of-bounds write in FFmpeg's MagicYUV decoder, CWE-787, CVSS 8.8), fixed upstream in FFmpeg 8.1.2.

This mirrors #1249, which already landed the same bump on 4.x (shipped in 4.14.0.94). 5.x was still building its manylinux/musllinux wheels against 8.1.1, so it remained exposed. Follow-up requested in #1248.

Changes

File(s) Change
docker/manylinux2014/Dockerfile_{aarch64,x86_64} FFMPEG_VERSION 8.1.1 → 8.1.2
docker/manylinux_2_28/Dockerfile_{aarch64,x86_64} FFMPEG_VERSION 8.1.1 → 8.1.2
docker/musllinux_1_2/Dockerfile_{aarch64,x86_64} FFMPEG_VERSION 8.1.1 → 8.1.2
.github/workflows/build_wheels_manylinux.yml manylinux DOCKER_IMAGE tags :20260531:20260725 (the same 8.1.2 images 4.x now ships)

Scope

  • The manylinux jobs build inside the prebuilt DOCKER_IMAGE, so pointing the tags at :20260725 is what actually delivers 8.1.2 into the wheels; the Dockerfile ARG bumps keep the recipes in sync.
  • The 5.x i686 build is on a separate, older FFmpeg 5.1.x line and is intentionally left unchanged here.

This only gets the fix into the branch — cutting/publishing the 5.x release is a maintainer action whenever you're ready. cc @asmorkalov @aremishevsky

MDSALMANSHAMS and others added 2 commits July 30, 2026 12:07
Mirrors opencv#1249 (merged on 4.x). Bumps the manylinux and musllinux
Dockerfiles from FFmpeg 8.1.1 to 8.1.2 and points the manylinux
DOCKER_IMAGE tags at the :20260725 images that ship 8.1.2, matching
the current 4.x branch. The i686 build is on a separate older 5.1.x
line and is left unchanged.
@MDSALMANSHAMS

Copy link
Copy Markdown
Contributor Author

@asmorkalov friendly ping on this one — it's the 5.x half of #1248 (the same CVE-2026-8461 FFmpeg 8.1.2 bump that shipped on 4.x in #1249), and CI has now settled.

Current state on 80634fcb: 199 success / 13 skipped / 1 failure. The single red job, Build (3.9, x64, 1, 1, 0) (macOS 13 arm64), built the wheel successfully — it fails at the very end on artifact upload:

##[error]Failed to CreateArtifact: Unable to make request: ETIMEDOUT

So that is a GitHub artifact-upload timeout after a clean build, not a build break. Worth noting it also confirms FFmpeg 8.1.2 compiles fine on macOS arm64.

The change is 7 files, +16/-16: FFMPEG_VERSION 8.1.1 → 8.1.2 in the six manylinux/musllinux Dockerfiles, plus the four manylinux DOCKER_IMAGE tags in build_wheels_manylinux.yml bumped :20260531:20260725 (the 8.1.2 images 4.x already ships) — that tag bump is what actually delivers 8.1.2 into the wheels. 5.x i686 is deliberately left on its older 5.1.4 line; jumping 32-bit to 8.x is a separate, riskier change and out of scope for a CVE hotfix.

Good to merge whenever you have a moment.

The other six Dockerfiles on this branch move 8.1.1 -> 8.1.2, but the i686
one was still pinned at 5.1.4. The 4.x counterpart (opencv#1249) covered this file,
so bump it here too to keep the branches consistent.
@MDSALMANSHAMS

Copy link
Copy Markdown
Contributor Author

Added one more file: docker/manylinux2014/Dockerfile_i686 was still pinned at FFMPEG_VERSION=5.1.4 on this branch while the other six move 8.1.1 -> 8.1.2. The 4.x counterpart #1249 covered that file, so this keeps the two branches consistent.

To be clear about scope: i686 is not in the wheel build matrix (platform: [x86_64, aarch64]) and no workflow references that Dockerfile, so no published wheel was affected - this is branch hygiene and keeps dependency scanners from flagging a 5.1.4 pin sitting in the tree. Same shape as #1233.

@MDSALMANSHAMS

Copy link
Copy Markdown
Contributor Author

@asmorkalov could you take a look at merging this? It closes the 5.x half of #1248 — 4.x already shipped the same bump in #1249 (released in 4.14.0.94), so 5.x is currently the only branch still exposed to CVE-2026-8461.

Since the red CI is the obvious reason to hesitate, here is what is actually failing.

The 9 red Test (3.x, x64) jobs are a PyPI index resolution failure on the runners, not this change. From the job log (Test (3.12, x64), head 2484e9ee):

WARNING: Retrying ... NewConnectionError('...: Failed to establish a new connection:
         [Errno 8] nodename nor servname provided, or not known'): /simple/pip/
WARNING: Retrying ... same error for /simple/numpy/
ERROR: Could not find a version that satisfies the requirement numpy>=2 (from versions: none)
ERROR: No matching distribution found for numpy>=2

The jobs die in pip install, before OpenCV or FFmpeg is ever configured or built, so an FFMPEG_VERSION bump cannot be the cause. It also hits unrelated Python versions equally (3.7 through 3.14), which is the signature of a mirror/DNS problem rather than a code problem. The same failure appeared on #1249 before it merged.

I did try to clear it: an empty commit on 08-02 re-ran the matrix clean (199 success / 1 unrelated artifact-upload timeout on macOS 13 arm64, after the wheel built fine). It came back on the next push and a second re-trigger on 08-06 did not clear it, so it is not transient from our side.

On the change itself: 6 Dockerfiles plus manylinux2014/Dockerfile_i686 go FFMPEG_VERSION 8.1.1 → 8.1.2, and build_wheels_manylinux.yml moves the 4 manylinux DOCKER_IMAGE tags from :20260531 to :20260725 — the workflow tag bump is what actually delivers 8.1.2 into the wheels, the ARG keeps the recipe in sync. This mirrors what is on 4.x today.

One scoping note in the interest of accuracy: Dockerfile_i686 is not in the wheel build matrix on either branch, so no published wheel was ever affected by that particular file — I included it so the two branches match, not because it shipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant