CVE-2026-61864

What it actually does

ImageMagick versions before 7.1.2-26 and 6.9.13-51 can leak a small amount of memory when a color transformation to the Log colorspace fails. The flaw does not provide code execution, privilege escalation, or data disclosure; its practical impact is limited availability degradation if the failing operation can be triggered repeatedly enough to accumulate leaked memory and exhaust process or host resources. The CVSS indicates low severity, local attack vector, high attack complexity, and low availability impact.

Why it matters to the business

The most likely business impact is degraded or unavailable image-processing functionality, such as failed uploads, delayed media conversion jobs, worker crashes, or increased infrastructure resource consumption. Because exploitation requires repeated triggering of a narrow failure condition and there is no known public exploit maturity, broad operational disruption is unlikely, but internet-facing or automated services that process untrusted images at scale should still patch during the normal maintenance cycle.

How an attack unfolds

An attacker would need a way to cause ImageMagick to perform a conversion involving the Log colorspace and make that transformation fail. This could occur through direct local use of ImageMagick tools or indirectly through an application, service, or batch pipeline that accepts user-controlled image files or transformation parameters. By repeatedly submitting inputs or requests that trigger the failing colorspace conversion, the attacker can cause small unreleased memory allocations to accumulate. Over time, this may increase memory pressure, cause ImageMagick worker processes to crash or be killed by the operating system, or degrade service availability. The vulnerability is not known to enable arbitrary code execution or access to image contents beyond what the application already processes.

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 bundled by an operating system, container image, language package, appliance, or application dependency, apply the vendor-provided patched package rather than relying only on upstream version strings. If immediate upgrade is not possible, reduce exposure by disabling unnecessary user-controlled colorspace transformations, restricting use of the Log colorspace where feasible, limiting image-processing request rates, applying memory and CPU limits to conversion workers, isolating ImageMagick execution in containers or sandboxes, and rejecting untrusted or unusually large image-processing workloads.

How to confirm the fix worked

Confirm that all ImageMagick binaries and libraries in use report a fixed version with commands such as `magick -version`, `convert -version`, package-manager inventory, container image scanning, or software composition analysis. Validate both primary tools and embedded consumers such as application libraries, background workers, and media-processing services. After patching, run representative image conversion tests that include colorspace transformations and confirm there is no abnormal memory growth during repeated failed conversions. For externally exposed services, verify that request throttling, worker memory limits, and sandboxing controls are active.

Typical attack path

1. Identify an application, script, or workflow that uses a vulnerable ImageMagick version before 7.1.2-26 or 6.9.13-51.
2. Find a reachable path that allows image conversion or transformation involving the Log colorspace, either through command-line options, API parameters, or application functionality.
3. Submit crafted or unsupported image input, transformation parameters, or malformed processing jobs that cause the Log colorspace transformation to fail.
4. Repeat the failing operation many times to accumulate leaked memory in ImageMagick or the surrounding worker process.
5. Cause availability impact through memory exhaustion, worker termination, job queue backlog, or degraded image-processing performance.

How to detect it

There are no known public exploitation campaigns or KEV listing for this vulnerability. To determine whether it was already abused, review application, web, job-queue, container, and host logs for repeated image-conversion failures involving Log colorspace transformations, especially if followed by rising memory usage, worker restarts, OOM kills, or failed upload/conversion requests. Useful sources include ImageMagick stderr/stdout logs, application media-processing logs, web access logs for image upload or conversion endpoints, job scheduler logs, container runtime events, systemd journals, kernel OOM logs, and APM metrics showing memory growth in image-processing workers. Look for high-frequency requests from the same source, repeated failed conversions with similar parameters, spikes in `magick` or `convert` process memory, and operating-system messages showing ImageMagick-related processes killed due to memory pressure. Because the vulnerability is a memory leak rather than a payload-based compromise, detection should focus on behavioral evidence of repeated triggering rather than post-compromise artifacts.

• -colorspace Log
• colorspace Log
• magick
• convert
• cache resources exhausted
• memory allocation failed
• Out of memory: Killed process
• Killed process magick
• Killed process convert
• oom-kill
• OOMKilled
• ImageMagick

What your security team should do

• Inventory all ImageMagick installations, including operating system packages, containers, build images, application bundles, and transitive dependencies used by media-processing workflows.
• Prioritize patching systems that process untrusted images, expose image upload or conversion features, or run high-volume automated conversion jobs.
• Upgrade to ImageMagick 7.1.2-26 or later, or 6.9.13-51 or later, using vendor-supported packages where applicable.
• Apply resource controls such as per-process memory limits, worker recycling, queue rate limits, and container isolation for image-processing services.
• Review application functionality that allows users to influence ImageMagick command options, especially colorspace transformations, and restrict unnecessary transformations.
• Monitor for repeated failed image conversions, sustained memory growth, OOM kills, worker restarts, or conversion job backlogs.
• Treat this as a low-severity availability issue unless telemetry shows active abuse or the vulnerable component supports a critical user-facing service.