CVE-2026-47166

What it actually does

ImageMagick versions before 6.9.13-48 and 7.1.2-23 contain a heap buffer over-read in the `magick -distribute-cache` server process. An attacker who can reach or otherwise interact with the distributed pixel cache service can cause the process to read beyond the bounds of an allocated heap buffer. The primary technical outcomes are disclosure of process memory and process instability or crash; the vulnerability is not described as enabling direct data modification or arbitrary code execution.

Why it matters to the business

Organizations using ImageMagick distributed cache services may face exposure of sensitive image-processing data or adjacent process memory, as well as outages in workflows that rely on ImageMagick for media conversion, thumbnailing, document processing, or graphics pipelines. The current public exploitation signal is low: EPSS is very low, there is no known CISA KEV listing, no ransomware association is reported, and exploit maturity is listed as none. However, because ImageMagick is commonly embedded in applications and automation pipelines, affected instances may be overlooked, especially in containers, bundled software, and background processing systems.

How an attack unfolds

An attacker first needs a path to interact with an ImageMagick distributed cache service, typically by having local/high-privilege access or by being able to connect to a running `magick -distribute-cache` server that has been exposed to reachable networks. The attacker then sends crafted cache-service traffic that triggers incorrect bounds handling in the server. When the vulnerable code processes the request, it reads past the end of a heap buffer. Depending on runtime behavior, this may return unintended memory contents to the attacker, terminate the process, generate a crash dump, or destabilize image-processing jobs that depend on the cache service. There is no public indication from the provided data that this issue is being actively exploited in the wild.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-48 or later for the 6.x branch, or 7.1.2-23 or later for the 7.x branch. Where operating-system packages use vendor backports, verify the vendor advisory confirms the patch is included even if the displayed upstream version appears older. Rebuild and redeploy containers, language-runtime images, appliances, and application bundles that include ImageMagick. If immediate upgrade is not possible, disable `magick -distribute-cache` where it is not required, restrict access to the distributed cache service to trusted local hosts or private management networks, enforce host firewalls, and avoid exposing the service to untrusted users or networks.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `identify -version`, or `convert -version`, and verify it is at least 6.9.13-48 or 7.1.2-23, or that the platform vendor has backported the fix. Search running processes for distributed cache usage, for example command lines containing `magick -distribute-cache`. Check listening sockets with tools such as `ss`, `netstat`, or endpoint inventory to ensure any distributed cache listener is not exposed beyond intended trusted hosts. Validate container images and application bundles by inspecting package manifests and rebuilding from patched base images. After patching, restart ImageMagick-related services and confirm no old vulnerable processes remain resident.

Typical attack path

1. Identify systems running ImageMagick, especially hosts or containers using distributed pixel cache functionality.
2. Determine whether a `magick -distribute-cache` service is running and reachable from the attacker’s position.
3. Establish access to the service or abuse existing local/high-privilege access consistent with the vulnerability’s preconditions.
4. Send crafted distributed-cache requests that exercise the vulnerable heap-buffer handling path.
5. Observe whether the service leaks memory contents, crashes, restarts, or disrupts dependent image-processing workflows.
6. Optionally repeat the interaction to collect additional leaked data or cause sustained denial of service.

How to detect it

To determine whether exploitation may already have occurred, review endpoint, process, and service logs for `magick` or ImageMagick distributed cache crashes, abnormal exits, segmentation faults, heap-buffer-read errors, core dump creation, or repeated restarts. Examine system journals, syslog, container logs, supervisor logs, crash reporters, and EDR telemetry around any `magick -distribute-cache` process. Review network flow logs and host firewall logs for unexpected clients connecting to distributed cache listeners, especially from untrusted subnets or user workstations. Look for repeated short-lived connections followed by ImageMagick crashes or service restarts. If core dumps exist, preserve them for forensic review because heap over-read conditions may expose memory contents. There are no provided public actor-specific indicators, payload signatures, or known malicious files for this vulnerability.

What your security team should do

• Prioritize patching systems where ImageMagick distributed cache services are enabled, reachable by multiple users, or connected to production media/document-processing workflows.
• Inventory ImageMagick installations across servers, containers, CI/CD images, appliances, and application dependencies; do not rely only on package managers from the base operating system.
• Upgrade to ImageMagick 6.9.13-48 or later, or 7.1.2-23 or later, and redeploy dependent workloads.
• Disable `magick -distribute-cache` unless there is a clear operational requirement for distributed pixel caching.
• Restrict any required distributed cache service with host firewalls, network segmentation, and least-privilege service accounts.
• Monitor for crashes, core dumps, abnormal restarts, and unexpected connections to ImageMagick distributed cache processes.
• Because EPSS is currently very low and there is no KEV listing, treat this as a targeted-hardening and exposure-reduction item rather than an emergency internet-wide exploitation event, unless the service is externally reachable.