CVE-2026-40962 in ffmpeg 8.0.1

[BGrasnick]

Please update ffmpeg to 8.1:
https://github.com/opencv/opencv-python/blob/4.x/docker/manylinux_2_28/Dockerfile_aarch64#L6

Here is the CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-40962

[simplelife2010]

See #1212

[MDSALMANSHAMS]

This should be resolved on 4.x. Every FFmpeg pin on that branch is now 8.1.2 - manylinux_2_28 (x86_64 + aarch64), manylinux2014 (x86_64, aarch64, i686) and musllinux_1_2 (x86_64 + aarch64) - via #1233 and #1249. The Dockerfile_aarch64 line this issue points at reads ARG FFMPEG_VERSION=8.1.2 today, well past the 8.1 asked for here.

5.x is the remaining half: it sits at 8.1.1, and #1255 moves it to 8.1.2 (i686 included as of just now). Once that merges both branches are clear of CVE-2026-40962 and CVE-2026-8461.

@asmorkalov this one looks closeable on 4.x already.

[asmorkalov]

The issue has been fixed in 4.x and 4.14.0 contains fresh FFmpeg version. It'll be merged to 5.x soon and updated with next release. See https://github.com/opencv/opencv-python/blob/4.x/docker/manylinux_2_28/Dockerfile_x86_64

[MDSALMANSHAMS]

@asmorkalov thanks for closing this.

On the 5.x side — that bump is already prepared and waiting in #1255 (open since 07-30). It mirrors the merged 4.x change exactly:

• six Dockerfiles, FFMPEG_VERSION 8.1.1 → 8.1.2 (manylinux_2_28 x86_64/aarch64, manylinux2014 x86_64/aarch64, musllinux_1_2 x86_64/aarch64)
• docker/manylinux2014/Dockerfile_i686, which was still pinned at 5.1.4 → 8.1.2. To be precise about scope: that file is not referenced by the wheel build matrix (platform: [x86_64, aarch64]), so no published wheel was ever affected by it — it is branch hygiene / scanner noise rather than a shipped CVE.
• the four DOCKER_IMAGE tag bumps in .github/workflows/build_wheels_manylinux.yml — this is the part that actually delivers 8.1.2 into the wheels, and it is easy to miss if only the Dockerfiles are updated.

8 files, +17/-17.

One thing that may be making the PR look worse than it is: it currently shows 9 red Test (3.x, x64) jobs. Those are not the change. They are a transient PyPI index resolution failure — NameResolutionError on /simple/numpy/, ending in ERROR: No matching distribution found for numpy>=2 — which dies inside pip install, before OpenCV or FFmpeg is configured at all. It hits 3.7 through 3.14 equally, which is the signature of a mirror/DNS problem rather than a build break. The build jobs are green, including the macOS arm64 wheel.

Happy to rebase onto current 5.x if that makes it easier to take.