CVE-2026-61866

What it actually does

ImageMagick versions before 7.1.2-26 contain a memory leak in the JNG encoder error path. When ImageMagick attempts to encode or process a malformed JNG image and the associated blob cannot be opened, memory is not released correctly. Repeated triggering can consume process or system memory and degrade availability. The CVSS vector indicates local attack conditions with high complexity and low availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Systems that use ImageMagick for image conversion, thumbnailing, upload processing, document pipelines, or media automation may experience increased memory consumption, failed jobs, degraded performance, or service restarts if exposed to crafted JNG inputs. The overall exploitation likelihood appears low based on the low EPSS score, absence from CISA KEV, and no known mature exploit, but organizations with automated image-processing workflows should still patch because repeated processing of malformed files can create operational instability.

How an attack unfolds

An attacker needs a path to make ImageMagick process a crafted JNG image, such as a local batch job, file-processing workflow, upload pipeline, or another application that invokes ImageMagick on attacker-supplied files. The malicious or malformed JNG content is designed to force the JNG encoder into a failure path where blob opening fails. In vulnerable versions before 7.1.2-26, this error path leaks memory instead of freeing it. A single attempt may have limited effect, but repeated submissions or automated reprocessing can gradually exhaust available memory for the ImageMagick process or the host, causing conversion failures, worker crashes, queue backlogs, or degraded service availability.

How to fix it

Upgrade ImageMagick to version 7.1.2-26 or later. If vendor packages are used, apply the relevant operating system or distribution security update that backports the fix. Where immediate patching is not possible, reduce exposure by blocking or disabling JNG processing if it is not required, enforcing strict file type and size limits, disabling automatic retries for failed conversions, running ImageMagick workers with memory and CPU limits, and isolating image-processing workloads in containers or sandboxed worker processes. Review ImageMagick policy.xml resource controls such as memory, map, area, disk, and time limits to constrain the impact of malformed inputs.

How to confirm the fix worked

Confirm the installed ImageMagick version reports 7.1.2-26 or later using commands such as `magick -version`, `convert -version`, or package-manager inventory. For distribution-maintained packages, verify the package changelog or security advisory confirms the CVE fix is backported. Validate that JNG handling is disabled if mitigation was chosen by reviewing ImageMagick policy.xml and testing that JNG inputs are rejected. In processing services, confirm workers have memory limits and that malformed image-processing failures do not produce sustained memory growth across repeated attempts.

Typical attack path

1. Identify an application, script, or service that uses ImageMagick to process JNG or user-supplied image files.
2. Provide a malformed JNG file that causes blob-opening operations to fail during encoding or conversion.
3. Cause the vulnerable ImageMagick code path to execute repeatedly, either through repeated submissions, batch processing, or retry behavior.
4. Accumulate leaked memory in the affected process or worker pool.
5. Trigger degraded performance, failed image-processing jobs, process termination, or resource-exhaustion conditions.

How to detect it

To determine whether this was already exploited or triggered, review application upload logs, media-processing worker logs, job queue records, system logs, and container orchestration events for repeated failures involving JNG files or ImageMagick commands followed by memory growth, worker restarts, OOM kills, or conversion timeouts. Search web and application logs for uploads or processing requests with `.jng` filenames or `image/jng` content types, especially repeated submissions from the same source. Review ImageMagick stderr/stdout logs for blob open failures, JNG coder errors, cache/resource-limit messages, or repeated failed conversions. At the host level, examine journald, syslog, kernel logs, container logs, and process supervisors for `magick`, `convert`, or application worker processes being killed due to memory exhaustion. No public threat actors or ransomware campaigns are currently associated with this vulnerability based on the provided data.

• .jng
• image/jng
• magick
• convert
• JNG
• unable to open blob
• cache resources exhausted
• memory allocation failed
• Killed process
• Out of memory
• oom-kill
• ImageMagick
• policy.xml

What your security team should do

• Inventory systems, containers, CI runners, media services, and application dependencies that invoke ImageMagick, especially those processing user-supplied images.
• Prioritize patching externally reachable or automated image-processing workflows to ImageMagick 7.1.2-26 or a vendor-fixed build.
• If patching is delayed, disable JNG support where unnecessary and enforce ImageMagick resource limits through policy.xml and container or service-level memory limits.
• Add monitoring for repeated ImageMagick failures involving JNG files, blob-open errors, rising worker memory, OOM kills, and image-processing queue backlogs.
• Review upload validation and content-disarm controls to ensure unsupported or malformed JNG files are rejected before reaching ImageMagick.
• Because this issue is not in KEV and has low EPSS, handle it through normal patch SLAs unless the environment heavily depends on untrusted image processing.