CVE-2026-53461

What it actually does

ImageMagick versions before 6.9.13-50 and 7.1.2-25 contain an incorrect loop in the ICON image decoder. When ImageMagick parses a specially crafted ICO file, the decoder can write outside the bounds of a heap buffer, causing memory corruption and typically terminating the ImageMagick process. The described impact is denial of service through a crash; there is no confirmed confidentiality or integrity impact and no public exploit maturity indicated in the supplied data.

Why it matters to the business

Services that automatically process user-supplied images can be disrupted by a malicious or malformed icon file. This may cause failed uploads, broken thumbnail generation, stalled media-processing queues, repeated worker restarts, increased operational load, and temporary unavailability of features that depend on ImageMagick. Although this vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, exposed image-processing workflows should still be patched because exploitation requires little complexity when untrusted image files are accepted.

How an attack unfolds

An attacker identifies an application, API, email gateway, document converter, CMS, CI pipeline, or backend worker that processes uploaded images with a vulnerable ImageMagick release. The attacker submits a crafted ICO file or a file that will be routed to the ICON decoder. When the backend invokes ImageMagick utilities or libraries to inspect, resize, convert, or thumbnail the file, the vulnerable loop in the decoder performs an out-of-bounds heap write. The most likely result is a process crash, which can interrupt the current request or job. Repeated submissions can cause recurring crashes, queue failures, container restarts, or degraded availability of image-processing services.

How to fix it

Upgrade ImageMagick to a patched release: 6.9.13-50 or later for the 6.x branch, or 7.1.2-25 or later for the 7.x branch. Update operating system packages, container base images, language-specific image-processing bundles, and any statically bundled ImageMagick copies. If immediate patching is not possible, temporarily block or quarantine ICO files from untrusted sources, disable ICON decoding where operationally feasible, isolate image-processing workers with resource limits and automatic restart controls, and run conversion in a sandbox with least privilege. Treat mitigations as temporary because the durable fix is upgrading the affected decoder code.

How to confirm the fix worked

Confirm the installed runtime version with commands such as `magick -version`, `convert -version`, or package-manager inventory, and verify it reports ImageMagick 6.9.13-50 or later, or 7.1.2-25 or later. Validate all execution locations, including containers, worker nodes, serverless layers, CI images, and embedded application dependencies. Confirm that vulnerable packages are absent from software composition analysis and container scans. Review upload-processing paths to ensure untrusted ICO files are either processed only by patched ImageMagick or blocked by policy. After upgrade, monitor for continued ImageMagick crashes during ICO processing, which may indicate an incomplete rollout or a separate decoder issue.

Typical attack path

1. Find an internet-facing or otherwise reachable workflow that accepts image files or archives/documents containing images.
2. Submit a crafted ICO file or content that causes ImageMagick to invoke the ICON decoder.
3. Wait for the application or background worker to process the file using a vulnerable ImageMagick version.
4. Trigger an out-of-bounds heap write during ICON parsing, causing the ImageMagick process to crash.
5. Repeat submissions to disrupt image conversion, thumbnail generation, or dependent application functionality.

How to detect it

To determine whether exploitation may have already occurred, correlate file-upload, API gateway, web server, application, job-queue, container, and endpoint telemetry. Look for ICO file submissions followed within seconds or minutes by ImageMagick process crashes, segmentation faults, abnormal exits, core dumps, worker restarts, or failed image-conversion jobs. Useful sources include web access logs, application upload logs, image-processing worker logs, syslog or journald, Kubernetes pod events, container runtime logs, EDR process telemetry, crash-reporting systems, and core dump directories. Pay particular attention to repeated ICO uploads from the same source, unusually small or malformed icon files, files with mismatched extensions and magic bytes, and repeated crashes of `magick`, `convert`, `identify`, or application processes that embed ImageMagick. There are no universally reliable network IOCs for this issue; detection should focus on suspicious ICO processing activity and crash correlation.

• .ico
• image/x-icon
• image/vnd.microsoft.icon
• ICO
• magick
• convert
• identify
• Segmentation fault
• SIGSEGV
• status=11/SEGV
• dumped core
• core dumped
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• coders/icon.c
• MagickCore
• MagickWand

What your security team should do

• Inventory all systems, containers, and applications that invoke ImageMagick directly or through image-processing libraries.
• Prioritize upgrades for internet-facing upload services, media platforms, document-processing systems, email/content scanners, and asynchronous image workers that accept untrusted files.
• Upgrade to ImageMagick 6.9.13-50 or later, or 7.1.2-25 or later, and rebuild/redeploy dependent container images and application packages.
• Until patched, restrict ICO uploads from untrusted users or route them to a sandboxed processing tier with strict CPU, memory, filesystem, and network limits.
• Add monitoring for ImageMagick process crashes, repeated worker restarts, and ICO uploads immediately preceding failures.
• Review crash dumps and recent upload logs for suspicious ICO files submitted before patch deployment.
• Because this is not KEV-listed and has low EPSS, handle through accelerated routine patching unless the organization exposes high-volume public image upload functionality, in which case treat as higher operational priority.