CVE-2026-56366

What it actually does

ImageMagick before 7.1.2-18 has a memory leak in the META reader when parsing APP1JPEG image-processing paths. A specially crafted JPEG file containing APP1 metadata can cause the ImageMagick process to allocate memory that is not released correctly. Repeated processing or processing in long-running services can gradually exhaust memory and degrade or interrupt availability. The vulnerability does not provide code execution, privilege escalation, or data disclosure based on the provided details; its impact is denial of service through resource exhaustion.

Why it matters to the business

Systems or applications that accept and process user-supplied images with ImageMagick may experience failed image conversions, degraded performance, worker crashes, or service interruptions if crafted images are processed repeatedly. The risk is lower than remote code execution because user interaction or an image-processing workflow is required, the CVSS score is low, EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported. However, internet-facing upload services, media processing queues, and batch conversion pipelines should still prioritize remediation because availability issues can affect customer-facing functionality and operational throughput.

How an attack unfolds

An attacker creates a JPEG image with crafted APP1 metadata that exercises the vulnerable APP1JPEG path in ImageMagick's META reader. The attacker then gets the target to process the file, such as by uploading it to an application, sending it through an image conversion pipeline, or placing it where an automated thumbnailing or metadata-extraction job will handle it. When ImageMagick versions before 7.1.2-18 parse the file, memory is leaked. A single file may cause limited impact, but repeated uploads, repeated conversions, or processing by a persistent worker can accumulate memory pressure until the service slows, fails jobs, is restarted by supervisors, or becomes unavailable.

How to fix it

Upgrade ImageMagick to version 7.1.2-18 or later wherever ImageMagick is installed or bundled. If using operating-system packages, apply the vendor-provided security update when available, as distribution package versions may backport fixes without matching upstream version numbers. Restart long-running services, workers, containers, and processing daemons after updating so patched libraries and binaries are loaded. As compensating controls, restrict untrusted image uploads, enforce file size and dimension limits, limit metadata processing where feasible, apply per-process memory and CPU limits, isolate image conversion in sandboxed workers or containers, and use queue rate limits to prevent repeated resource-exhaustion attempts.

How to confirm the fix worked

Confirm exposure by inventorying ImageMagick installations and checking the runtime version with commands such as `magick -version`, `convert -version`, or package-manager queries. Systems reporting ImageMagick earlier than 7.1.2-18 should be considered vulnerable unless the operating-system vendor documents a backported fix. Validate remediation by confirming the patched version or vendor advisory status, then restarting services that call ImageMagick. For applications, verify that image upload and conversion paths still function and that resource limits are enforced. Where safe and authorized, use a non-malicious regression test from the upstream project or vendor advisory rather than untrusted proof-of-concept files.

Typical attack path

1. Identify an application, service, or workflow that uses ImageMagick to process JPEG uploads or imported image files.
2. Craft or obtain a JPEG file with APP1 metadata that triggers the vulnerable META reader APP1JPEG path.
3. Submit the file through an upload form, API, email ingestion flow, shared folder, or other image-processing entry point.
4. Cause the target to process the crafted file once or repeatedly using a vulnerable ImageMagick version before 7.1.2-18.
5. Repeat submissions or trigger retries to increase memory consumption.
6. Observe degraded performance, failed conversions, worker restarts, queue backlog, or temporary denial of service.

How to detect it

To determine whether exploitation may already have occurred, review application upload logs, API gateway logs, web server logs, image-processing worker logs, container logs, system journals, and monitoring data for repeated JPEG upload or conversion attempts followed by memory growth, failed conversions, process termination, or out-of-memory conditions. Focus on periods with spikes in image-processing errors, repeated submissions from the same source, queue backlogs, container restarts, or kernel OOM-killer activity involving ImageMagick processes such as `magick`, `convert`, `identify`, or application workers invoking those binaries. Inspect suspicious uploaded JPEGs for APP1/Exif metadata and preserve samples for analysis. Because this vulnerability is a memory leak rather than code execution, durable host artifacts may be limited; absence of shell activity or persistence does not rule out denial-of-service attempts.

• ImageMagick
• magick
• convert
• identify
• APP1
• APP1JPEG
• Exif
• META reader
• memory allocation failed
• cache resources exhausted
• no images defined
• Killed process
• Out of memory: Killed process
• oom-killer
• oom_reaper
• exit code 137
• SIGKILL
• container restarted
• worker restarted

What your security team should do

• Inventory all applications, containers, build images, and hosts that include ImageMagick, especially internet-facing upload services and asynchronous media-processing workers.
• Upgrade ImageMagick to 7.1.2-18 or a vendor package containing the backported fix, then restart dependent services and redeploy affected containers.
• Prioritize externally reachable image-upload and conversion workflows even though EPSS is low and the issue is not in CISA KEV.
• Add or verify memory, CPU, file-size, pixel-dimension, request-rate, and queue-depth limits around ImageMagick processing.
• Isolate image processing from core application services using sandboxed workers, containers, seccomp/AppArmor/SELinux policies, and least-privilege execution.
• Monitor for repeated image-processing failures, worker restarts, out-of-memory events, and spikes in JPEG uploads with APP1/Exif metadata.
• Block or quarantine suspicious image uploads that repeatedly trigger processing failures or excessive memory consumption.
• Track vendor advisories for distribution-specific fixed package versions if upstream version 7.1.2-18 is not directly available.