CVE-2026-61869

What it actually does

ImageMagick contains a memory leak in the MIFF encoder path before versions 7.1.2-26 and 6.9.13-51. When MIFF image processing reaches a memory-allocation failure condition, memory that should be released is retained, allowing repeated or resource-intensive processing attempts to gradually consume available memory. The direct impact is reduced availability of the ImageMagick process or the service that embeds it; confidentiality and integrity are not expected to be affected.

Why it matters to the business

The likely consequence is service instability or outage for applications that rely on ImageMagick to convert, resize, thumbnail, or otherwise process images, especially where users can upload files or trigger image conversion jobs. The published severity and EPSS are low, it is not listed in CISA KEV, and there is no reported exploit maturity, so this should generally be handled through normal patch cycles unless ImageMagick is exposed through high-volume or externally reachable processing workflows.

How an attack unfolds

An attacker first needs a way to cause ImageMagick to perform MIFF encoding or a conversion workflow that reaches the MIFF encoder. In a local scenario, this could be direct access to run ImageMagick tools; in an application scenario, it could be an upload, document-processing, media-processing, or thumbnailing feature that invokes ImageMagick on attacker-controlled content or parameters. The attacker then submits inputs or repeated jobs designed to force memory pressure and allocation failure during MIFF processing. Because the vulnerable encoder leaks memory on that failure path, repeated triggering can increase memory consumption until the ImageMagick process slows, crashes, is killed by the operating system, or causes the surrounding application worker to become unavailable.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-26 or later for the 7.x branch, or 6.9.13-51 or later for the 6.x branch. Where ImageMagick is supplied by an operating system or distribution package, install the vendor-provided patched package because vendors may backport fixes without changing the upstream version string. If immediate patching is not possible, reduce exposure by disabling or restricting MIFF read/write support where not required, applying ImageMagick resource limits in policy.xml, limiting memory and CPU for image-processing workers, enforcing upload size and pixel-dimension limits, and isolating conversion jobs in containers or sandboxed worker pools.

How to confirm the fix worked

Confirm the installed ImageMagick version with `magick -version`, `convert -version`, package-manager metadata, or container image manifests, and verify it is at or above 7.1.2-26 or 6.9.13-51, or that the OS vendor advisory confirms a backported fix. Validate that all application runtimes, containers, worker images, CI build images, and serverless layers using ImageMagick have been rebuilt or redeployed with the patched package. If MIFF is not needed, confirm policy restrictions prevent MIFF encoding/decoding. Operationally, run representative image-processing workloads after patching and verify that memory usage remains stable under failed or rejected conversions.

Typical attack path

1. Identify an application, batch job, or local workflow that uses ImageMagick for image conversion or MIFF output.
2. Gain the ability to submit images, request conversions, or run ImageMagick commands that exercise the MIFF encoder.
3. Trigger memory-allocation failure conditions through resource-intensive processing or repeated conversion attempts.
4. Repeat the operation to accumulate leaked memory in ImageMagick or the hosting worker process.
5. Cause degraded performance, process termination, job queue failures, or denial of service for dependent image-processing functionality.

How to detect it

There are no widely reported public exploitation artifacts for this issue, so detection should focus on signs of attempted denial of service through ImageMagick MIFF processing. Review application logs, upload service logs, job queue logs, ImageMagick stderr/stdout, web access logs, container logs, system logs, and EDR telemetry for repeated conversions involving MIFF, unusual volumes of failed image-processing jobs, memory-allocation errors, resource-limit errors, worker restarts, crashes, or operating-system out-of-memory kills involving ImageMagick processes. Correlate spikes in requests for image upload/conversion endpoints with rapid memory growth in `magick`, `convert`, or application worker processes. In containerized environments, inspect orchestrator events for OOMKilled containers running image-processing workloads. Treat detections as behavioral indicators rather than definitive proof, because memory exhaustion can also be caused by legitimate large images or misconfigured resource limits.

• magick
• convert
• mogrify
• MIFF
• miff
• id=ImageMagick
• memory allocation failed
• cache resources exhausted
• unable to extend cache
• OOMKilled
• Out of memory: Killed process
• Killed process magick
• Killed process convert
• .miff

What your security team should do

• Inventory systems, containers, applications, and media-processing pipelines that include ImageMagick, especially externally reachable upload or conversion services.
• Patch ImageMagick to 7.1.2-26 or later, 6.9.13-51 or later, or the relevant vendor-backported package.
• Prioritize externally reachable, multi-tenant, high-volume, or automated image-processing services even though the public exploitation likelihood is currently low.
• Disable or restrict MIFF support if the format is not business-required.
• Enforce ImageMagick resource policies, OS-level memory limits, upload size limits, and worker isolation to reduce denial-of-service impact.
• Monitor image-processing workers for repeated MIFF conversions, allocation failures, abnormal memory growth, crashes, and out-of-memory kills.
• Ensure container base images and application dependencies are rebuilt after package updates, not merely patched on long-running hosts.