CVE-2026-25986 is a medium severity flaw (CVSS 5.3) in ImageMagick, where ReadYUVImage writes one pixel beyond the allocated row buffer when it processes malicious YUV 4:2:2 images with no interlacing. The weakness is CWE-787, an out-of-bounds write. Upgrade to ImageMagick 7.1.2-15 or 6.9.13-40, the patched releases. It is not listed in CISA's KEV catalog.
What's affected
- ImageMagick 7.x before 7.1.2-15
- ImageMagick 6.9.x before 6.9.13-40
- Fixed in 7.1.2-15 and 6.9.13-40
The advisory lists no workaround. Upgrading is the remedy it names. Many other products embed ImageMagick through libraries such as Magick++, so the version of the command line tool on your laptop may not be the one that matters.
How to check if you're exposed
Check the version of the tool on each host that converts images:
magick -version
convert -version
The second command covers older 6.x installs. Then look for bundled copies: language bindings, container images and application packages that ship their own ImageMagick. A system package manager only reports what it installed itself.
Safeguard has a free in-browser dependency scan at https://gold.safeguard.sh/scan that reads a manifest or lockfile and flags known vulnerable packages, with no repository access needed. For container images, check the package list of the image rather than the host.
What to do now
- Upgrade to 7.1.2-15 or 6.9.13-40 or later, through your distribution package or by rebuilding from the project's release.
- Rebuild and redeploy container images and applications that bundle ImageMagick, then confirm the version inside the running image.
- Find the services that accept uploads from users or fetch images from outside and note which ones call ImageMagick.
- Where upgrading must wait, limit which formats ImageMagick will decode using its policy file, which is a general hardening step and not something this advisory prescribes.
- Keep ImageMagick in your software inventory so the next advisory is a lookup, not a search.
Why it matters
The advisory pins this to ReadYUVImage() in coders/yuv.c. The pixel pair loop writes one pixel past the end of the row buffer it allocated. That is an off by one style error: small in size, but a heap write is still a write.
The record scores it 5.3 with an availability impact. Cases like this are a good reminder that obscure formats such as YUV are still decoded by default builds, so the attack surface of an image tool is wider than the formats your users actually upload.
The class matters for triage. Image decoders run on bytes you do not control, so any memory safety bug in a coder is reachable wherever your product accepts an image. Reachability analysis helps here: it shows whether your code actually calls the vulnerable coder, so you can order the upgrades by real exposure instead of by score alone.
Quick check
Is this one exploited in the wild?
The record does not flag it as a CISA KEV entry, and the advisory we read does not report exploitation. Treat it as a patch-soon item, not an incident.
Do I use YUV files?
Probably not, but the question is whether your build can decode them. Upgrading removes the question. Restricting formats through the policy file is the alternative if an upgrade has to wait.
Sources
Last reviewed: 19 October 2026.
