CVE-2026-56371

What it actually does

ImageMagick releases before 7.1.2-15 and 6.9.13-40 can leak memory while parsing crafted TXT image files that include texture attributes. The vulnerable TXT coder allocates a texture image object through ReadImage and, if GetTypeMetrics fails, does not release that object. A single file may have limited effect, but repeated processing of malicious TXT inputs can steadily increase process memory consumption and potentially cause denial of service through worker crashes, container restarts, or host memory pressure.

Why it matters to the business

Services that accept or transform untrusted images, documents, avatars, attachments, or uploaded media using ImageMagick may be vulnerable to resource exhaustion. Successful abuse could interrupt image-processing queues, slow dependent applications, crash conversion workers, increase infrastructure costs through repeated restarts, and degrade customer-facing upload or rendering functionality. This issue is not currently in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so urgency is highest for internet-facing or automated file-processing systems rather than all installations equally.

How an attack unfolds

An attacker identifies an application or service that uses ImageMagick to process user-supplied files and that permits TXT image input or auto-detects file formats. The attacker submits a specially crafted TXT image containing a texture attribute designed to trigger a GetTypeMetrics failure after ImageMagick has allocated a texture object. In vulnerable versions, that object is not freed. By repeating the submission or causing the service to process many such files, the attacker accumulates leaked memory in the ImageMagick process or its worker container. Eventually the process may be killed by the operating system, restarted by orchestration, or slowed due to memory pressure, causing denial of service for image conversion workflows.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-15 or later for the 7.x branch, or 6.9.13-40 or later for the 6.x branch. Where ImageMagick is supplied by an operating-system package, apply the vendor security update and verify whether the vendor has backported the fix even if the displayed upstream version appears older. If immediate upgrade is not possible, reduce exposure by disabling TXT image decoding where not required, rejecting or strictly validating TXT image uploads, forcing allow-listed file types, running ImageMagick with memory/time/file-size limits, and isolating conversion workers with container or OS-level resource limits. Consider ImageMagick policy.xml limits for memory, map, area, disk, width, height, and time, and ensure worker supervisors use bounded retry behavior to avoid amplification.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `convert -version`, or the relevant package manager query, and verify it is 7.1.2-15 or later, 6.9.13-40 or later, or a vendor-backported fixed build. Review application dependency manifests and container images to ensure no embedded or statically packaged vulnerable ImageMagick binaries remain. Validate mitigations by confirming TXT input is blocked or policy-restricted where not needed. In a non-production test environment, process a representative crafted TXT file that exercises texture handling and monitor resident memory over repeated runs; fixed builds should not show unbounded memory growth from this failure path.

Typical attack path

1. Find an application endpoint, batch job, or API that accepts user-controlled files and processes them with ImageMagick.
2. Submit or queue a crafted TXT-format image containing a texture attribute.
3. Trigger the vulnerable TXT coder path where ReadImage allocates a texture object and GetTypeMetrics fails.
4. Repeat submissions to cause cumulative memory leakage in conversion workers.
5. Exhaust process, container, or host memory, leading to worker crashes, failed conversions, queue backlog, or service degradation.

How to detect it

This issue is a memory-leak denial-of-service condition, so exploitation is unlikely to leave a durable payload artifact. Focus detection on operational evidence around ImageMagick execution and file-processing workflows. Review application upload logs, API gateway logs, job queue records, web server logs, container runtime events, systemd logs, kernel logs, and EDR process telemetry for repeated processing of TXT image files shortly before memory spikes or worker crashes. Look for ImageMagick processes such as `magick` or `convert` repeatedly invoked on `.txt` inputs, especially files containing texture attributes, followed by exceptions, failed conversions, OOM killer messages, container restarts, or queue retry storms. In containerized environments, inspect orchestration events for `OOMKilled`, high restart counts, and correlated upload activity. For forensics, collect recent submitted files, temporary conversion directories, and application error logs, then grep candidate TXT inputs for texture-related attributes. Absence of these artifacts does not prove non-exploitation, because the primary effect is transient resource exhaustion rather than persistence or code execution.

• OOMKilled
• Out of memory: Killed process
• Killed process
• Memory cgroup out of memory
• magick
• convert
• GetTypeMetrics
• coders/txt.c
• texture
• *.txt

What your security team should do

• Inventory all services, containers, serverless functions, CI jobs, and batch processors that invoke ImageMagick on untrusted or semi-trusted files.
• Prioritize patching internet-facing upload, preview, document-conversion, thumbnailing, and media-processing workflows to ImageMagick 7.1.2-15/6.9.13-40 or vendor-fixed packages.
• Disable TXT coder support or enforce file-type allow lists if TXT image processing is not a business requirement.
• Apply strict resource controls around ImageMagick execution, including memory, CPU time, file size, pixel area, process isolation, and queue throttling.
• Search recent logs for repeated TXT conversion failures, memory exhaustion events, worker restarts, and upload patterns involving files with texture attributes.
• Add monitoring for abnormal memory growth in image-processing workers and alert on repeated OOM kills or conversion crashes.