CVE-2026-33535

What it actually does

ImageMagick versions before 7.1.2-18 and 6.9.13-43 contain a memory corruption flaw in the X11 display interaction path. When the vulnerable display code path is exercised locally, the process can perform an out-of-bounds write of a null byte, which can corrupt adjacent memory and crash the ImageMagick process. Based on the published severity and vector, the expected impact is denial of service to the local image display operation rather than data theft, privilege escalation, or remote code execution.

Why it matters to the business

The primary operational risk is disruption of systems, workflows, or desktop/session environments that rely on ImageMagick's X11 display functionality for image viewing or processing. The severity is moderate-to-low because exploitation is local, no known public exploit maturity is reported, EPSS is very low and flat, and the vulnerability is not listed in CISA KEV or known ransomware use. Organizations with packaged software, image tooling, developer workstations, kiosk systems, or automation that invokes ImageMagick should still patch because ImageMagick is widely reused and often installed as a dependency.

How an attack unfolds

An attacker who can execute ImageMagick locally, or influence a local workflow that launches the X11 display interaction path, triggers the vulnerable display handling logic. The malformed or edge-case interaction causes ImageMagick to write a zero byte outside the intended memory boundary. That memory corruption can destabilize the process and cause a crash. There is no current indication from the provided data that attackers can exploit this remotely, gain code execution, access sensitive data, or escalate privileges; the practical outcome is expected to be availability loss for the affected ImageMagick operation.

How to fix it

Upgrade ImageMagick to a patched release: 7.1.2-18 or later for the 7.x branch, or 6.9.13-43 or later for the 6.x branch. Use operating system vendor packages where available, because downstream distributions may backport the fix while retaining older-looking version strings. If immediate upgrade is not possible, reduce exposure by disabling or avoiding X11 display functionality on systems that do not need it, preventing untrusted users from launching ImageMagick display operations, and isolating image-handling workloads in least-privileged containers or restricted desktop sessions.

How to confirm the fix worked

Confirm installed ImageMagick versions with package-manager inventory and command-line checks such as `magick -version`, `convert -version`, or `display -version`, then verify they are at or above 7.1.2-18 or 6.9.13-43, or that the OS vendor advisory confirms the fix has been backported. Validate that applications or scripts no longer invoke vulnerable unpatched binaries. On Linux systems, review package metadata from tools such as rpm, dpkg, apk, brew, or container image scanners, and verify container/base images have been rebuilt after the patched package was installed.

Typical attack path

1. Gain local ability to run ImageMagick tools or influence a local process that invokes ImageMagick's X11 display functionality.
2. Trigger the vulnerable X11 display interaction path using crafted input, invocation parameters, or display interaction conditions.
3. Cause an out-of-bounds null-byte write in the ImageMagick process memory.
4. Crash the affected display or magick process, interrupting the image handling workflow.
5. Optionally repeat the trigger to create recurring denial of service for dependent local workflows.

How to detect it

To determine whether this issue may already have been triggered, review endpoint and system logs for crashes of ImageMagick X11 display components. Useful sources include Linux journald/syslog, kernel logs, auditd or EDR process execution telemetry, desktop session logs, application logs from tools that call ImageMagick, and crash dump systems such as systemd-coredump, apport, ABRT, or macOS crash reports where applicable. Look for repeated or suspicious executions of `display`, `magick display`, or ImageMagick-linked tools immediately followed by segmentation faults, aborts, core dumps, or service/application failures. Because the known impact is crash-oriented and no public exploit indicators or threat actor activity are provided, absence of these artifacts does not prove non-exploitation, and presence of a crash should be correlated with command-line arguments, user identity, working directory, input file provenance, and timing.

• process_name=display
• process_name=magick
• command_line="magick display"
• command_line="display"
• ImageMagick
• Segmentation fault
• segfault at
• core dumped
• systemd-coredump
• Process display dumped core
• Process magick dumped core
• /usr/bin/display
• /usr/bin/magick
• /usr/local/bin/display
• /usr/local/bin/magick

What your security team should do

• Prioritize patching systems that expose ImageMagick to multiple local users, shared desktop sessions, CI/build workers, image-processing automation, or packaged applications that invoke X11 display functionality.
• Upgrade to ImageMagick 7.1.2-18 or later, or 6.9.13-43 or later, using trusted vendor packages or rebuilt application/container images.
• Inventory indirect ImageMagick installations because it is commonly present as a dependency of image, document, media, and web tooling.
• If patching is delayed, restrict local execution of ImageMagick display functionality and remove ImageMagick from systems that do not require it.
• Monitor for repeated crashes of `display`, `magick`, or ImageMagick-linked applications, especially where untrusted local users can trigger image display workflows.
• Track vendor advisories for distribution-specific fixed package names and backported patches, since package version strings may differ from upstream ImageMagick versions.