CVE-2026-86421

What it actually does

ImageMagick's Magick Scripting Language (MSL) decoder fails to free heap allocations after parsing a crafted MSL image. Repeated decode operations therefore grow resident memory without a corresponding free, eventually exhausting the process or host and causing a denial of service. There is no confidentiality or integrity impact; availability impact is limited (low-severity DoS) and requires high attack complexity plus additional prerequisites.

Why it matters to the business

Services that convert, thumbnail, or inspect untrusted images with ImageMagick can slow, crash, or be restarted by the OOM killer, interrupting previews, uploads, and media pipelines. CVSS 3.7, no CISA KEV listing, no ransomware association, and exploit maturity of None nearly a month after publication indicate low operational urgency compared with remote code execution, but organizations that expose ImageMagick to untrusted files still face availability risk if the MSL coder is enabled.

How an attack unfolds

An unauthenticated attacker prepares a malicious MSL image designed to force allocations that the decoder never releases. The file is delivered through any path that causes ImageMagick to decode it (upload, preview, thumbnail, email gateway, or automated conversion). Each decode leaks memory; sustained or repeated submissions drive the worker toward exhaustion so the process stalls or is killed, denying image-processing service. No known threat actors or in-the-wild campaigns are associated with this issue.

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, via vendor or distribution packages. If immediate upgrade is not possible, disable the MSL coder (for example by removing or restricting the MSL entry in coder policy.xml, or by not installing MSL support) and avoid passing untrusted files to convert/magick/identify/mogrify. Restart long-running ImageMagick workers after the change so leaked memory is not retained. Prefer processing images in isolated, memory-capped workers so a leak cannot take down the host.

How to confirm the fix worked

Confirm installed ImageMagick is 7.1.2-30+, 6.9.13-55+, or a distribution backport that includes the MSL leak fix (magick -version / convert -version). Verify the MSL coder is absent or policy-denied if it is not required. After upgrade or policy change, exercise the image pipeline with benign MSL and common formats and watch that worker RSS remains stable under repeated decode. Inventory hosts and containers that ship ImageMagick (web apps, CMS, document preview, CI) to ensure none remain on vulnerable builds.

Typical attack path

1. Identify an application or pipeline that decodes untrusted images with ImageMagick and has the MSL coder enabled.
2. Craft an MSL image that triggers allocation without matching deallocation in the MSL decoder.
3. Submit the file via an exposed ingest path (upload, conversion API, preview, or batch job).
4. Repeat or sustain processing until the ImageMagick process or host memory is exhausted.
5. Observe worker crash, hang, or OOM restart, resulting in denial of image-processing service.

How to detect it

This is a resource-exhaustion flaw with no public exploit, so look for effects rather than a unique payload. Review ImageMagick worker logs and host metrics around image ingest for unexplained RSS growth, OOM killer events, and repeated convert/magick/identify/mogrify crashes while handling uploads. Inspect application access and upload logs for requests that submit Magick Scripting Language content (.msl, format MSL) to conversion or preview endpoints. Correlate spikes in ImageMagick memory with those requests; absence of MSL ingest and stable memory makes prior exploitation unlikely. There are no associated APT or ransomware artifacts.

• \.msl
• format\s*[:=]\s*MSL
• coder.*MSL
• Magick: MSL
• process: magick
• process: convert
• process: identify
• process: mogrify
• ImageMagick.*out of memory
• oom-kill.*(?:magick|convert|identify|mogrify)
• Killed process.*(?:magick|convert|identify|mogrify)

What your security team should do

• Patch ImageMagick to 7.1.2-30+ or 6.9.13-55+ on all image-processing hosts and container images; treat this as a scheduled availability fix, not an emergency KEV response.
• Disable or policy-restrict the MSL coder wherever MSL input is not a business requirement.
• Run ImageMagick in memory-limited sandboxes or separate workers so a leak cannot starve co-located services.
• Block or quarantine unexpected .msl uploads at the application edge if MSL is unused.
• Track distribution and base-image updates so rebuilt containers pick up the fixed library.