CVE-2026-53460

What it actually does

This vulnerability is a denial-of-service flaw in ImageMagick's memory allocation path. Before ImageMagick 6.9.13-50 and 7.1.2-25, the AcquireAlignedMemory function does not sufficiently enforce a maximum memory request check. A specially crafted image or image-processing request can cause ImageMagick to request excessive memory, leading to an out-of-memory condition. The primary impact is availability loss: the ImageMagick process, the calling application, a container, or in severe cases the host can become unstable or terminate. There is no known confidentiality or integrity impact from the vulnerability as described.

Why it matters to the business

Applications that accept, transform, thumbnail, validate, convert, or inspect images using vulnerable ImageMagick versions may be vulnerable to remote service disruption. An attacker may be able to repeatedly submit malicious image content and exhaust memory, causing failed uploads, broken media processing, degraded user-facing services, failed background jobs, container restarts, or broader host instability. The EPSS score is currently low and there is no known CISA KEV listing or ransomware association, but ImageMagick is widely embedded in web applications, document pipelines, CMS platforms, CI systems, and backend media services, so exposure may be indirect through downstream software.

How an attack unfolds

An attacker identifies an application or API endpoint that processes attacker-supplied images using ImageMagick, such as upload validation, thumbnail generation, format conversion, metadata extraction, or document preview generation. The attacker submits a crafted image or image-like payload designed to drive ImageMagick into an oversized aligned-memory allocation through the vulnerable AcquireAlignedMemory path. Because vulnerable versions do not properly cap the memory request, the process consumes excessive memory and can trigger an out-of-memory condition. Depending on deployment architecture, this may crash the ImageMagick process, terminate the worker process that invoked it, restart a container, exhaust a job queue, or degrade the host. Repeated requests can convert a single crash into sustained denial of service.

How to fix it

Upgrade ImageMagick to a patched version: 6.9.13-50 or later for the ImageMagick 6 branch, or 7.1.2-25 or later for the ImageMagick 7 branch. Also update operating system packages, language bindings, container base images, and bundled application dependencies that include ImageMagick. Where immediate upgrade is not possible, reduce exposure by rejecting untrusted image formats that are not required, enforcing strict upload size and pixel-dimension limits, running ImageMagick in isolated containers or sandboxes, applying resource limits through ImageMagick policy.xml, cgroups, container memory limits, ulimit, or job worker quotas, and rate-limiting unauthenticated image-processing endpoints. Ensure application queues have retry limits so repeated crashes do not create persistent backlog amplification.

How to confirm the fix worked

Confirm the installed ImageMagick version with `magick -version`, `convert -version`, or package-manager inventory and verify it is at least 6.9.13-50 or 7.1.2-25 depending on the major branch. Check container images and application build artifacts as well as host packages, because ImageMagick is often bundled indirectly. Validate that image-processing services still function after upgrade and that memory limits are enforced by testing oversized, malformed, and high-resolution image inputs in a controlled non-production environment. Confirm that policy.xml or container resource controls prevent unbounded memory growth. For exposed services, verify that upload limits, file type validation, request rate limits, and job retry limits are active.

Typical attack path

1. Find an exposed feature that accepts or retrieves untrusted image files for processing.
2. Confirm that the backend uses ImageMagick or a wrapper/library that invokes ImageMagick commands or APIs.
3. Submit a malformed or specially crafted image payload that triggers excessive memory allocation in vulnerable ImageMagick versions.
4. Cause the ImageMagick process or calling application worker to consume excessive memory and fail.
5. Repeat submissions to keep workers, containers, or queues in a degraded or unavailable state.

How to detect it

To determine whether exploitation may already have occurred, review application, web server, worker, container orchestration, operating system, and job queue logs for memory exhaustion events correlated with image uploads, conversions, metadata extraction, or thumbnail generation. Look for repeated crashes or restarts of processes such as `magick`, `convert`, `identify`, web workers, queue workers, or containers immediately after processing unusual image files. On Linux, inspect kernel and system logs for OOM-killer activity involving ImageMagick or the application process invoking it. In Kubernetes or containerized environments, review pod restart counts, OOMKilled statuses, container memory limit events, and request logs for repeated submissions from the same source around the time of restarts. In application logs, look for ImageMagick exceptions related to memory allocation, resource exhaustion, cache exhaustion, or failed image reads. Preserve suspicious uploaded files, request metadata, source IPs, user agents, and timestamps for controlled analysis; do not open or process suspected files on production systems.

• AcquireAlignedMemory
• cache resources exhausted
• memory allocation failed
• unable to allocate memory
• out of memory
• OOMKilled
• Killed process
• invoked oom-killer
• magick
• convert
• identify
• MagickCore
• MagickWand
• policy.xml

What your security team should do

• Inventory all direct and indirect ImageMagick usage, including web upload handlers, media services, document preview systems, CI jobs, CMS plugins, container images, and language bindings.
• Prioritize patching internet-facing or unauthenticated image-processing paths to ImageMagick 6.9.13-50+ or 7.1.2-25+.
• Apply defense-in-depth memory and CPU limits to all ImageMagick execution contexts, even after patching.
• Restrict accepted file types, maximum file size, pixel dimensions, and conversion workflows to business-required use cases only.
• Monitor for repeated ImageMagick crashes, out-of-memory events, worker restarts, and spikes in image-processing queue failures.
• Add abuse controls such as authentication, rate limiting, request body limits, and retry caps around endpoints that process user-supplied images.
• Update base images and downstream packages to avoid reintroducing vulnerable ImageMagick versions during future deployments.