CVE-2025-53644 is a Critical severity memory flaw (CVSS 9.8) in OpenCV 4.10.0 and 4.11.0. An uninitialized pointer on the stack can lead to an arbitrary heap buffer write when the library reads a crafted image. Version 4.12.0 fixes it, so upgrade to that release or later.
What's affected
The record lists OpenCV versions 4.10.0 and 4.11.0 as affected. Version 4.12.0 contains the fix.
The GitHub Security Lab write-up says the bug is in the JPEG 2000 decoder path. It was tested on v4.11.0. According to its coordinated disclosure timeline, a fix was merged to the 4.x branch on 13 May 2025 and v4.12.0 was released on 2 July 2025.
OpenCV is rarely used alone. It is bundled in Python wheels, Docker base images, robotics stacks and desktop applications, so the version you must check is the one inside each of those, not only the one you installed yourself.
How to check if you're exposed
Start with the library version your code actually loads:
python -c "import cv2; print(cv2.__version__)"
pip list 2>/dev/null | grep -i opencv
npm ls opencv4nodejs 2>/dev/null
For system packages and container images, use the package manager or an image scan:
dpkg -l | grep -i libopencv
A reported version of 4.10 or 4.11 means you are in the affected range. Then ask which of those services decode images that came from outside. Those are the ones to fix first.
What to do now
- Upgrade OpenCV to 4.12.0 or later in every environment, including container base images, and rebuild images that bundle it.
- Pin the new version in your lock files so an older build cannot return through a cached layer.
- Until you upgrade, avoid decoding JPEG 2000 images from untrusted sources in services that use OpenCV.
- Run image processing workers with low privileges, in a sandbox and with no secrets in their environment.
- Run a dependency scan to find copies of OpenCV nested inside other packages that are easy to miss.
Why it matters
This is CWE-457, use of an uninitialized variable. The GitHub Security Lab report explains that a pointer called rawImage is declared but not set before it is passed to the OpenJPEG header reading function. If that function fails, the pointer keeps whatever garbage was on the stack, and a caller that does not check the result then writes through it.
That turns a missing return value check and a missing initial value into a memory write controlled in part by the image. Initialising the pointer to null and checking the result are both one line fixes, which is why bugs of this kind are common and easy to prevent.
The record is not in the CISA Known Exploited Vulnerabilities catalogue. The advisory does not claim attacks. Image libraries sit in a lot of pipelines, so the exposure is usually wider than a team expects.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to upgrade if I never use JPEG 2000 files?
The flaw is in the decoder path described by the advisory. If you can prove that no JPEG 2000 data ever reaches the library, your risk is lower, but upgrading is still the simplest fix.
How do I find OpenCV inside other packages?
Use a software bill of materials or a dependency scan, since wheels and images often bundle their own copy that the package manager does not list separately.
Sources
- NVD record
- GitHub Security Lab advisory GHSL-2025-057
- OpenCV 4.12.0 release
- Gold record for CVE-2025-53644
Last reviewed: 18 October 2026.
