CVE-2026-61868

What it actually does

ImageMagick versions before 7.1.2-26 and 6.9.x before 6.9.13-51 contain a memory leak in the YUV decoder error path. When ImageMagick attempts to open a YUV image blob and that open operation fails, allocated memory is not properly released. An attacker who can repeatedly cause ImageMagick to process specially crafted or malformed YUV input can gradually consume memory, potentially degrading or denying service to the application, worker process, or host performing image processing. The flaw affects availability only; it does not indicate code execution, data theft, or integrity compromise.

Why it matters to the business

Systems that accept or process user-supplied images may experience increased memory consumption, unstable image-processing workers, failed uploads, degraded service performance, or temporary outages if the issue is repeatedly triggered. The risk is lower than many remote code execution flaws because exploitation requires a specific failure condition and repeated triggering, and current public exploitation signals are low: EPSS is 0.00222, the flaw is not in CISA KEV, is not known to be used in ransomware campaigns, and no exploit maturity is reported. However, ImageMagick is commonly embedded in web applications, content management systems, media pipelines, document converters, CI systems, and backend processing jobs, so exposure may exist indirectly through dependencies.

How an attack unfolds

An attacker first identifies an application or service that uses a vulnerable ImageMagick build to parse or transform uploaded, fetched, or otherwise attacker-controlled image content. The attacker then submits malformed or specially constructed YUV content designed to reach the YUV decoder path and cause blob opening to fail. Because the vulnerable error path leaks memory, a single attempt may have little visible effect, but repeated submissions can accumulate unreleased memory in the image-processing process or associated worker pool. Over time, this can lead to high memory pressure, process crashes, worker restarts, queue backlogs, failed conversions, or broader service degradation if resource controls are weak.

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.9.x branch. Where ImageMagick is provided by an operating system or container base image, apply the vendor security update and rebuild/redeploy dependent applications and images. If immediate upgrading is not possible, reduce exposure by disabling or restricting YUV decoding if not required, enforcing strict file type validation, rejecting unexpected raw YUV inputs, limiting image dimensions and file sizes, applying per-process/container memory limits, using job timeouts, limiting conversion concurrency, and isolating image processing in a sandboxed worker separate from critical application processes.

How to confirm the fix worked

Confirm the deployed ImageMagick version with commands such as `magick -version`, `convert -version`, or package manager queries, and verify it is 7.1.2-26 or later, or 6.9.13-51 or later for the 6.9 branch. For containerized deployments, inspect both runtime containers and base images because applications may bundle their own ImageMagick binaries or libraries. Review application dependency manifests and system packages for embedded ImageMagick use. After patching, restart all services, workers, and containers that may have loaded the vulnerable libraries. Validate operational resilience by testing image upload/conversion workflows, monitoring memory usage during malformed image handling, and confirming workers do not show progressive memory growth under repeated failed YUV processing attempts.

Typical attack path

1. Identify an externally reachable workflow that processes images or media using ImageMagick, such as uploads, URL-based image imports, thumbnail generation, document conversion, or media transcoding.
2. Confirm or infer that YUV image handling is enabled and that the deployed ImageMagick version is older than 7.1.2-26 or, for the 6.9 branch, older than 6.9.13-51.
3. Submit malformed YUV input that causes the decoder to enter the blob-open failure path.
4. Repeat the request many times, potentially across concurrent connections or jobs, to accumulate leaked memory.
5. Observe service slowdown, image-processing failures, worker crashes, container restarts, or denial of service effects.

How to detect it

To determine whether this was already exploited, review logs and telemetry from services that accept uploads, fetch remote media, create thumbnails, convert documents, or otherwise invoke ImageMagick. Focus on the period since publication and any earlier unexplained service instability. Useful sources include web access logs, application upload/conversion logs, worker queue logs, container orchestration events, process supervisor logs, system memory metrics, kernel OOM logs, and ImageMagick error output. Look for repeated failed processing of YUV files or inputs labeled as YUV, spikes in conversion errors, repeated invocations of `magick` or `convert`, steadily increasing RSS memory for image-processing workers, out-of-memory kills, process restarts, 5xx responses around upload/conversion endpoints, and high-volume submissions from the same source. Because no widely known public exploit indicators or threat actor campaigns are reported for this CVE, detection should emphasize behavioral signs of repeated malformed image processing and resource exhaustion rather than fixed attacker infrastructure.

• YUV
• yuv
• YUV decoder
• UnableToOpenBlob
• unable to open blob
• no decode delegate for this image format
• magick
• convert
• identify
• composite
• montage
• OOMKilled
• Out of memory
• Killed process
• Memory cgroup out of memory
• CrashLoopBackOff
• ImageMagick
• MagickCore
• MagickWand

What your security team should do

• Inventory all direct and indirect ImageMagick usage across applications, containers, CI jobs, media-processing services, and third-party components.
• Prioritize internet-facing or user-supplied image-processing workflows for upgrade to ImageMagick 7.1.2-26 or later, or 6.9.13-51 or later.
• Rebuild and redeploy containers or packages that statically bundle ImageMagick rather than relying only on host-level patching.
• Apply compensating controls where patching is delayed: file type allowlisting, upload size limits, memory limits, worker isolation, request throttling, and conversion timeouts.
• Add monitoring for abnormal memory growth, repeated image conversion failures, worker crashes, and restart loops in services that process images.
• Because this is not currently in CISA KEV, not associated with ransomware, and has low EPSS, handle as a standard availability-risk patch unless the affected service is externally exposed or business-critical.