CVE-2026-56365

What it actually does

ImageMagick versions before 7.1.2-19 contain a memory leak in the PNG encoder path when writing MNG images. If an attacker can cause a vulnerable ImageMagick installation to encode or convert content into MNG format and trigger the encoder failure condition, memory is not released correctly. Repeated or sustained triggering can exhaust available memory and degrade or terminate the ImageMagick process or the hosting service. The impact is denial of service rather than code execution or data compromise.

Why it matters to the business

Services that accept, transform, resize, validate, or generate images using ImageMagick may become slow, unstable, or unavailable if exposed to malicious or malformed image-processing requests. The risk is lower than a remote code execution issue because exploitation requires a specific image-writing workflow and the public exploit maturity is currently listed as none, with low EPSS and no CISA KEV listing; however, internet-facing upload or media-processing services can still experience operational disruption if the vulnerable encoder path is reachable.

How an attack unfolds

An attacker first identifies an application or service that uses ImageMagick for image processing and allows user-supplied files, image conversion jobs, thumbnails, previews, document rendering, or media normalization. The attacker then submits content or a request that causes ImageMagick to write an MNG image through the vulnerable PNG encoder path. By crafting the input or job parameters to hit the encoder failure condition, the vulnerable process leaks memory instead of releasing it. A single attempt may have limited effect, but repeated requests or parallel jobs can steadily increase memory consumption until the ImageMagick worker, container, job runner, or host reaches memory limits. The result is failed conversions, process crashes, restarts, degraded performance, or broader service denial if shared worker capacity is exhausted.

How to fix it

Upgrade ImageMagick to version 7.1.2-19 or later wherever ImageMagick is installed, including application containers, build images, worker nodes, server packages, and embedded dependencies. If immediate upgrade is not possible, reduce exposure by disabling or blocking MNG output where it is not business-critical, restricting supported output formats to a safe allowlist, limiting file size and pixel dimensions, enforcing per-request CPU and memory limits, running ImageMagick in isolated worker processes or containers, and rate-limiting unauthenticated or untrusted image-processing requests. Review ImageMagick policy.xml controls to disable unneeded coders and enforce resource ceilings for memory, map, disk, width, height, area, and time.

How to confirm the fix worked

Confirm the installed ImageMagick version reports 7.1.2-19 or later using package inventory, container image scans, and direct version checks such as `magick -version` or `convert -version` where applicable. Verify that application images and runtime hosts have been rebuilt or redeployed after the upgrade, not only patched in source repositories. If MNG support is not required, validate that attempts to write MNG output are rejected by policy. Exercise representative image-processing workflows after remediation and confirm memory usage returns to baseline after failed or invalid conversion attempts. For compensating controls, confirm resource limits, format allowlists, and rate limits are enforced in production-like conditions.

Typical attack path

1. Find an application endpoint, API, batch job, or workflow that uses ImageMagick to process user-controlled images or generate MNG output.
2. Submit image-processing requests that cause ImageMagick to invoke the MNG writer and PNG encoder.
3. Trigger the encoder failure condition that causes memory to be leaked.
4. Repeat the request or run concurrent jobs to accumulate unreleased memory.
5. Exhaust process, container, or host memory, causing conversion failures, worker crashes, restarts, or service unavailability.

How to detect it

To determine whether this was already exploited, review application access logs, API gateway logs, upload logs, job queue records, and image-processing service logs for repeated or unusual requests that produce or request MNG output, especially from the same source over a short period. Correlate those events with spikes in memory usage, container OOM events, ImageMagick worker crashes, failed conversion jobs, autoscaling events, and service restarts. On Linux systems, inspect syslog, journald, kernel logs, and container runtime events for OOM-killer activity involving ImageMagick processes such as `magick` or `convert`. Review ImageMagick stderr/stdout logs and application exception logs for repeated encoder, allocation, cache, or write failures involving MNG or PNG handling. The observable artifacts are primarily behavioral and operational; they indicate possible exploitation or probing but are not uniquely attributable to this vulnerability without correlation to MNG-writing activity on a vulnerable version.

• .mng
• image/x-mng
• video/x-mng
• MNG
• magick
• convert
• memory allocation failed
• cache resources exhausted
• unable to write image data
• no images defined
• Out of memory: Killed process
• oom-kill
• OOMKilled
• Killed process

What your security team should do

• Prioritize patching internet-facing image upload, conversion, thumbnailing, preview, and media-processing services that use ImageMagick.
• Upgrade all ImageMagick installations to 7.1.2-19 or later, including containers and indirect package dependencies.
• Disable MNG read/write support if it is not explicitly required by the business workflow.
• Apply strict ImageMagick resource limits through policy.xml and container or process-level memory limits.
• Restrict accepted input and output formats with an allowlist rather than relying on user-supplied extensions or MIME types.
• Add monitoring for repeated MNG conversion attempts, ImageMagick failures, worker restarts, and memory exhaustion events.
• Because this issue is not currently in CISA KEV and has low EPSS with no known public exploit maturity, treat it as a stability and exposure-reduction priority rather than an emergency remote-code-execution event unless the vulnerable path is externally reachable.