CVE-2026-56364

What it actually does

ImageMagick versions before 7.1.2-13 contain a memory leak in the OpenCL device benchmark profile loader, specifically in LoadOpenCLDeviceBenchmark(). When ImageMagick parses a malformed OpenCL device profile XML file containing unclosed device elements, memory is not released correctly. An attacker who already has write access to the OpenCL cache directory can plant a crafted XML profile and cause ImageMagick processes that load OpenCL benchmark data to consume excessive memory, leading to local denial of service. The flaw does not provide code execution, privilege escalation, data disclosure, or data modification based on the published details.

Why it matters to the business

The likely operational impact is service instability or outage for systems that use ImageMagick to process images, especially shared servers, batch processing workers, CI/CD jobs, media pipelines, or web applications where image conversion runs automatically. Exploitation requires local write access to the relevant OpenCL cache location and is rated low severity, but affected systems may still experience memory exhaustion, failed image processing jobs, degraded performance, or process crashes if an attacker or compromised local account can write malicious OpenCL profile files.

How an attack unfolds

An attacker first needs a foothold or account that can write to the ImageMagick OpenCL cache directory used by the target process. The attacker then creates or modifies an OpenCL device benchmark profile XML file so that it contains malformed device entries, such as unclosed device elements. When an affected ImageMagick version later initializes OpenCL support and calls LoadOpenCLDeviceBenchmark() to parse the cached benchmark profile, the malformed XML triggers a memory leak. Repeated parsing, repeated job execution, or automated image-processing workflows can cause memory consumption to grow until the ImageMagick process, worker, container, or host becomes unstable or unavailable. Because the vulnerability requires high privileges or a specific local write condition and has no known public exploit maturity, it is most relevant as a local denial-of-service risk or as an impact amplifier after another compromise.

How to fix it

Upgrade ImageMagick to version 7.1.2-13 or later. If ImageMagick is supplied by an operating system distribution, apply the vendor-provided security update rather than relying only on upstream version strings, because distributions may backport the fix. Where immediate patching is not possible, reduce exposure by disabling OpenCL acceleration for ImageMagick, for example by setting MAGICK_OCL_DEVICE=OFF for ImageMagick execution environments, rebuilding without OpenCL support where practical, or using runtime policy and service configuration to prevent OpenCL initialization. Restrict write permissions on ImageMagick cache/configuration directories so only the intended service account can write them, and avoid shared writable cache locations across users. Apply memory limits, process timeouts, container limits, and job isolation for image-processing workloads to contain denial-of-service impact.

How to confirm the fix worked

Confirm the installed ImageMagick version is 7.1.2-13 or later, or that the operating system vendor has backported the relevant fix. Validate using commands such as magick -version, identify -version, convert -version, and the local package manager. Review whether ImageMagick was built with OpenCL support and whether OpenCL is enabled in the runtime environment. Check the effective OpenCL cache/profile directory permissions and verify that untrusted users or application upload paths cannot write to it. Confirm compensating controls by ensuring MAGICK_OCL_DEVICE=OFF is present where OpenCL is intentionally disabled, and test that image-processing services continue to operate under memory limits. For high-assurance validation, inspect the installed source/package changelog for the fix to LoadOpenCLDeviceBenchmark() or the vendor advisory referencing this issue.

Typical attack path

1. Gain local access, application-level file-write capability, or control over a user account that can write to the ImageMagick OpenCL cache directory.
2. Identify the OpenCL cache/profile location used by the ImageMagick process or influence environment variables so ImageMagick reads a writable cache path.
3. Place or modify a malformed OpenCL device profile XML file containing unclosed device elements.
4. Trigger ImageMagick functionality that initializes OpenCL and loads the cached device benchmark profile.
5. Repeat or wait for normal image-processing jobs to invoke the vulnerable parser, causing cumulative memory leakage.
6. Exhaust available memory or container limits, resulting in failed conversions, killed processes, degraded service, or denial of service.

How to detect it

Look for evidence that an attacker wrote malformed OpenCL device profile XML files into ImageMagick cache or configuration locations before memory exhaustion events. Relevant data sources include file integrity monitoring, EDR file-write telemetry, Linux auditd, Windows Sysmon file creation events, container filesystem change logs, ImageMagick application logs, service manager logs, kernel out-of-memory logs, and package/version inventory. Investigate unexpected XML files in ImageMagick OpenCL cache directories, especially files containing repeated or unclosed <device> elements. Correlate those file writes with execution of magick, convert, identify, mogrify, composite, or application workers that call ImageMagick, followed by abnormal memory growth, OOM killer activity, process restarts, or failed image-processing jobs. On Linux, review syslog, journalctl, dmesg, audit logs, and container runtime events for out-of-memory kills involving ImageMagick processes. On Windows, review Sysmon Event ID 11 for suspicious profile XML creation and Application/System event logs for process termination or resource exhaustion. Because exploitation requires write access to a local cache path, any confirmed malicious profile file should trigger investigation of the account, application feature, or prior vulnerability that allowed the write.

• LoadOpenCLDeviceBenchmark
• MAGICK_OCL_DEVICE=OFF
• ImagemagickOpenCLDeviceProfile
• ImageMagickOpenCLDeviceProfile
• <device
• </device
• magick
• convert
• identify
• mogrify
• composite
• Out of memory: Killed process
• Killed process
• oom-killer
• Cannot allocate memory
• .cache/ImageMagick
• ImageMagick/cache
• OpenCL
• OpenCL device profile

What your security team should do

• Patch ImageMagick to 7.1.2-13 or a vendor-fixed build during the next normal maintenance window, prioritizing internet-facing or multi-tenant image-processing systems.
• Disable ImageMagick OpenCL support with MAGICK_OCL_DEVICE=OFF where OpenCL acceleration is not required.
• Audit permissions on ImageMagick cache and OpenCL profile directories; remove write access for untrusted users, shared service accounts, and application upload paths.
• Add or verify memory limits, process limits, job timeouts, and container resource controls for all automated ImageMagick workloads.
• Search for malformed OpenCL profile XML files, unexpected writes to ImageMagick cache directories, and recent memory-exhaustion events involving magick, convert, identify, or application workers that invoke ImageMagick.
• Monitor for repeated ImageMagick restarts, out-of-memory kills, or spikes in memory usage following access to OpenCL profile files.
• Treat suspected exploitation as a sign of prior local write access or compromise and investigate how the attacker obtained permission to write to the OpenCL cache location.