CVE-2026-47165

What it actually does

Prior to ImageMagick 6.9.13-48 and 7.1.2-23, the distributed pixel cache feature did not use a challenge-response authentication model. If the distributed pixel cache is enabled, a suitably positioned and highly privileged local attacker may be able to interact with or impersonate cache components and access cached pixel data generated during image processing. The primary impact is confidentiality exposure of image contents or derived pixel data; the flaw does not directly provide code execution, privilege escalation, or data modification.

Why it matters to the business

Organizations that process sensitive images, scans, design files, medical imagery, identity documents, or other confidential visual content with ImageMagick could face unauthorized disclosure if distributed pixel caching is enabled and reachable by an attacker. Operational risk is lower for default or single-host deployments that do not use distributed pixel cache. This issue is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity reported, so broad emergency response is generally not warranted unless the distributed cache feature is in use for sensitive workloads.

How an attack unfolds

An attacker first needs substantial access: the vulnerability is local, high-complexity, and requires high privileges according to the assigned CVSS vector. The attacker identifies an ImageMagick deployment using the distributed pixel cache feature, observes or determines how cache clients and cache servers communicate, and then connects to or impersonates a cache participant because older versions did not authenticate peers using challenge-response. If successful, the attacker can retrieve or observe pixel cache data associated with image-processing jobs. The likely end result is disclosure of image content or intermediate pixel data rather than direct system compromise.

How to fix it

Upgrade ImageMagick to a version that includes challenge-response authentication for distributed pixel cache: ImageMagick 6.9.13-48 or later for the 6.x branch, or ImageMagick 7.1.2-23 or later for the 7.x branch. If immediate upgrade is not possible, disable distributed pixel cache where it is not required, restrict any cache service to trusted local interfaces, block untrusted access to cache ports with host and network firewalls, and ensure only trusted users can modify ImageMagick configuration and job parameters. For package-managed installations, use the vendor-supported patched package for the operating system distribution even if the package version string differs from upstream.

How to confirm the fix worked

Confirm the installed ImageMagick version with `magick -version`, `convert -version`, or the operating system package manager, and verify it is at least 6.9.13-48 or 7.1.2-23, or that the distribution vendor has backported the fix. Review ImageMagick configuration, service definitions, container images, batch jobs, and command-line invocations for use of distributed pixel cache options. Confirm no distributed cache listener is exposed to untrusted users or networks. After remediation, test representative image-processing workflows to ensure distributed cache behavior still works as expected or remains disabled where not needed.

Typical attack path

1. Gain high-privilege access to a system or processing environment where ImageMagick is installed.
2. Determine whether ImageMagick distributed pixel cache is enabled or whether cache hosts are configured for image-processing jobs.
3. Identify local processes, command-line arguments, configuration files, or network listeners associated with distributed cache operation.
4. Connect to, monitor, or impersonate a distributed pixel cache component in the absence of challenge-response authentication.
5. Extract cached pixel data from image-processing activity and reconstruct or infer sensitive image contents.

How to detect it

Look for evidence that distributed pixel cache was enabled and accessed unexpectedly. Useful sources include process command-line telemetry, shell history, systemd service definitions, container entrypoints, ImageMagick job logs, network flow logs, host firewall logs, and EDR network/process events. Hunt for ImageMagick processes started with distributed cache options, unexpected listeners associated with ImageMagick, or connections from unapproved local users or hosts to cache services. Because this issue concerns missing authentication rather than a distinctive exploit payload, exploitation may leave few unique artifacts; focus on anomalous cache feature usage, unusual peer connections, and access to image-processing systems by privileged accounts outside normal administrative activity. No named threat actors or public exploit campaigns are currently associated with this CVE based on the provided data.

• -distribute-cache
• cache:hosts
• distributed pixel cache
• magick -distribute-cache
• convert -distribute-cache
• /etc/ImageMagick-6/policy.xml
• /etc/ImageMagick-7/policy.xml
• /usr/local/etc/ImageMagick-6/policy.xml
• /usr/local/etc/ImageMagick-7/policy.xml
• magick -version
• convert -version

What your security team should do

• Inventory ImageMagick installations across servers, containers, build agents, media-processing pipelines, and applications that handle uploaded or sensitive images.
• Prioritize upgrade for systems that process confidential images and use distributed pixel cache.
• Upgrade to ImageMagick 6.9.13-48 or later, 7.1.2-23 or later, or an OS-vendor package that backports the authentication change.
• Disable distributed pixel cache unless there is a documented operational requirement.
• Restrict cache-related network exposure to trusted hosts only and monitor for unexpected distributed cache listeners or command-line options.
• Because EPSS is very low and the issue is not in KEV, handle non-distributed-cache deployments through normal patch cycles, while validating that the feature is not enabled.