CVE-2026-86420

What it actually does

ImageMagick versions before 7.1.2-30 (7.x) and 6.9.13-55 (6.x) do not reduce the process memory budget when an operation inside OpenPixelCache fails. Failed cache operations can leave budget charged, so repeating those failures can exhaust Magick's memory resource limit and starve later allocations. Impact is limited to availability of the ImageMagick process (CVSS 3.7, VA:L); confidentiality and integrity are not affected. Exploitation requires network access, high attack complexity, and additional attack conditions, with no privileges or user interaction.

Why it matters to the business

Image conversion, thumbnailing, preview, and document-to-image pipelines that use affected ImageMagick builds can become slow, crash, or stop serving requests, interrupting user-facing media features and batch jobs. Severity is low, the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none about 29 days after publication, so mass opportunistic abuse is unlikely. Risk is still material wherever untrusted images are processed in-process rather than in isolated workers, because a single worker crash or memory lockup can take down a shared conversion service.

How an attack unfolds

An unauthenticated remote actor targets a service that decodes or transforms attacker-supplied images with a vulnerable ImageMagick build. They send inputs that cause internal OpenPixelCache operations to fail. Because the library does not lower the memory budget after those failures, each attempt leaves less remaining budget. Repeating the pattern under the required conditions can exhaust the process limit so new allocations fail and the worker stops handling legitimate work. This is a resource-exhaustion denial of service only; it does not yield code execution or data theft, and no in-the-wild campaigns or named threat actors are associated with this CVE.

How to fix it

Upgrade ImageMagick 7.x to 7.1.2-30 or later, or ImageMagick 6.x to 6.9.13-55 or later, including distro packages, language bindings, and containers that vendor the library. Rebuild or redeploy any application that statically links or bundles libMagick. Until patched, process untrusted media in isolated, memory-capped workers with Magick resource limits (memory, map, disk, area, time) and strict format/size allowlists; avoid decoding untrusted files in long-lived, shared processes. Confirm transitive copies in CI images, serverless layers, and desktop conversion tools.

How to confirm the fix worked

Inventory hosts, containers, and application dependencies for ImageMagick/libMagick and record the exact version (magick -version, convert -version, or package manager). Treat 7.x below 7.1.2-30 and 6.x below 6.9.13-55 as exposed. After upgrade, verify the running binary and linked library match the fixed release, restart long-lived workers, and smoke-test conversion paths. Optionally confirm Magick memory/map/disk limits and that untrusted uploads are handled in isolated workers. Re-scan images and lockfiles so bundled copies are not left behind.

Typical attack path

1. Find an application or API that processes untrusted images, PDFs, or similar media with ImageMagick (upload, thumbnail, preview, or conversion).
2. Send requests that cause OpenPixelCache operations to fail inside the ImageMagick process.
3. Repeat those requests so unreclaimed memory budget accumulates.
4. Drive the process to its Magick memory limit so further processing fails or the worker becomes unresponsive.
5. Sustain or rotate traffic to keep image-processing capacity degraded for other users.

How to detect it

This CVE has no known in-the-wild exploitation, no KEV listing, and no associated threat actors, so hunting is for resource-exhaustion symptoms rather than a known implant. Review ImageMagick worker logs (magick, convert, mogrify, and app logs that wrap them) for repeated cache or memory allocation failures around media uploads. Correlate with process-level memory growth, Magick resource-limit errors, crash loops, and OS OOM kills of conversion processes. On Linux, inspect journald/syslog OOM records, container restart counts, and APM traces showing spikes of failed image jobs from one client. Network logs showing a burst of image-upload or conversion requests followed by worker death are more useful than a single file hash. Absence of these signals does not prove the bug was never triggered; it only means a noisy DoS may not have occurred.

• Memory allocation failed
• cache resources exhausted
• Pixel cache allocation failed
• OpenPixelCache
• convert: memory
• magick: memory
• mogrify: memory
• oom-kill.*convert
• oom-kill.*magick
• process_name:convert
• process_name:magick
• process_name:mogrify

What your security team should do

• Patch ImageMagick to 7.1.2-30+ or 6.9.13-55+ on all internet-facing and batch conversion systems first.
• Inventory every runtime that ships ImageMagick (app servers, serverless, CI, desktop agents) and track residual 6.x vs 7.x lineages.
• Run untrusted image work in memory-capped, restartable workers with Magick resource limits and format allowlists.
• Watch conversion workers for repeated allocation failures, OOM kills, and unexplained restarts; treat clusters of events as a possible abuse signal.
• Do not prioritize this as an emergency relative to RCE/KEV issues: CVSS 3.7, not KEV, exploit maturity none, but do not leave shared in-process converters unpatched.