CVE-2026-56368

What it actually does

ImageMagick before 7.1.2-15 leaks memory in multiple image coders that write raw pixel data because allocated objects are not properly freed after processing. A specially crafted image can cause the affected process to steadily consume memory during conversion, thumbnailing, metadata extraction, or other ImageMagick-backed processing. The security impact is denial of service: memory exhaustion can slow or terminate the image-processing worker, container, web service, batch job, or host depending on deployment limits. The CVSS score is low at 3.7 and exploitation complexity is high, with no known public exploit maturity reported, but the issue is remotely reachable wherever untrusted images are accepted and processed automatically.

Why it matters to the business

Organizations that use ImageMagick to process uploaded or externally supplied images may experience service degradation, failed image uploads, delayed media processing, crashed workers, increased infrastructure costs from repeated restarts, or broader instability if memory limits are not enforced. The vulnerability is not known to enable data theft or code execution, and it is not listed in CISA KEV or associated with ransomware campaigns, but it can still affect availability for image-heavy services and automated document or media pipelines. EPSS is currently very low at 0.0026, suggesting limited near-term likelihood of broad exploitation, so remediation should be scheduled based on exposure to untrusted image processing rather than treated as an emergency for all deployments.

How an attack unfolds

An attacker identifies an application, API, email gateway, CMS, media service, CI pipeline, or backend job that uses a vulnerable ImageMagick version to process images. The attacker submits one or more specially crafted image files designed to exercise the vulnerable raw-pixel-writing coder paths. When ImageMagick parses or converts the image, memory allocated by the affected coders is not released correctly. Repeated submissions, large files, or concurrent processing can increase memory pressure until the ImageMagick process, its worker, container, or host reaches memory limits. The result is a denial-of-service condition such as failed conversions, terminated worker processes, HTTP errors, queue backlogs, or temporary service unavailability. No authentication is required at the ImageMagick layer, but practical exploitation depends on whether the surrounding application allows attacker-controlled images to be processed.

How to fix it

Upgrade ImageMagick to version 7.1.2-15 or later wherever it is installed directly or bundled in containers, application images, serverless layers, CI workers, media-processing services, or third-party packages. If distribution packages backport fixes without using upstream version numbering, verify the vendor security advisory or package changelog confirms the fix for CVE-2026-56368. Because no fixed package versions were provided in the input, use the upstream fixed baseline of 7.1.2-15 or the relevant operating-system vendor’s patched release. As compensating controls, enforce strict memory and CPU limits for image-processing workers, isolate ImageMagick in containers or sandboxes, restrict accepted image formats to those actually required, reject oversized or malformed images before conversion, process untrusted images asynchronously with queue-level rate limits, and use ImageMagick policy.xml controls to disable unnecessary coders and resource-heavy operations.

How to confirm the fix worked

Confirm installed ImageMagick versions with commands such as `magick -version`, `convert -version`, package-manager inventory, container image scans, and software composition analysis. Validate that all reachable image-processing paths use ImageMagick 7.1.2-15 or a vendor-backported fixed build. Review container base images and application bundles because older ImageMagick binaries may remain even after host packages are updated. Exercise normal image upload and conversion workflows after patching to confirm functionality. Validate mitigations by checking that resource limits are active, such as ImageMagick policy limits, cgroup/container memory limits, worker timeouts, and queue rate limits. Exposure exists if a vulnerable version processes images supplied by unauthenticated users, external partners, public URLs, email attachments, or other untrusted sources.

Typical attack path

1. Find an internet-facing or otherwise reachable feature that accepts or fetches images for processing, conversion, resizing, preview generation, or metadata extraction.
2. Confirm or infer that the backend uses ImageMagick before 7.1.2-15.
3. Create or obtain a crafted image that triggers one of the affected raw-pixel-writing coder paths.
4. Submit the crafted image through upload, URL import, email attachment, API request, or batch-processing input.
5. Repeat the submission or trigger concurrent processing to amplify memory consumption.
6. Cause the ImageMagick process, worker pool, container, or host to exhaust available memory and fail, restart, or become degraded.
7. Optionally continue sending crafted inputs to keep the service unstable or unavailable.

How to detect it

To determine whether exploitation already occurred, review application, web server, upload service, media worker, container runtime, orchestration, and operating-system logs for memory exhaustion or repeated image-processing crashes correlated with image uploads or conversion requests. Useful sources include HTTP access logs for upload or image-import endpoints, application error logs, ImageMagick wrapper logs, job queue logs, Kubernetes events, container runtime logs, systemd journals, kernel OOM logs, and infrastructure metrics showing memory spikes. Look for repeated failures from `magick`, `convert`, `identify`, or application workers processing unusual image files, especially where many requests originate from the same IP address, user agent, account, or URL-import source. Investigate timestamps where memory usage rose sharply, workers restarted, conversions timed out, queues backed up, or containers were OOMKilled. Preserve suspicious uploaded files and analyze them in an isolated environment only; do not reprocess them on production systems. There are no public threat actors, ransomware campaigns, or known exploit-specific network signatures provided for this vulnerability, so detection should focus on behavioral evidence of crafted-image-triggered memory exhaustion.

• ImageMagick before 7.1.2-15
• magick
• convert
• identify
• cache resources exhausted
• memory allocation failed
• unable to allocate memory
• Cannot allocate memory
• std::bad_alloc
• Killed process
• Out of memory: Killed process
• oom-killer
• OOMKilled
• exit code 137
• signal: killed
• Memory cgroup out of memory
• FailedToStartContainer
• Back-off restarting failed container
• policy.xml
• resource limits exceeded
• cache resources exhausted

What your security team should do

• Inventory all ImageMagick deployments, including containers, build agents, media workers, CMS plugins, document-processing tools, and application dependencies.
• Prioritize patching systems that process untrusted or internet-supplied images, especially upload endpoints, public APIs, email ingestion, and URL-based image fetchers.
• Upgrade to ImageMagick 7.1.2-15 or later, or apply the relevant vendor-backported patched package.
• Apply memory, CPU, file-size, timeout, and concurrency limits to image-processing workloads to reduce denial-of-service impact.
• Disable unused ImageMagick coders and risky processing features through policy.xml, allowing only required formats and operations.
• Add monitoring for repeated image-processing failures, worker restarts, out-of-memory kills, queue backlogs, and spikes in memory consumption.
• Because this is not KEV-listed, has no reported exploit maturity, and has very low EPSS, handle as risk-based remediation rather than emergency patching unless the service is exposed to high-volume untrusted image input.