CVE-2026-33536

What it actually does

This is a memory-corruption flaw in ImageMagick before 7.1.2-18 and 6.9.13-43. On certain platforms, an incorrect return value can cause a pointer to be advanced past the end of a stack-based buffer, leading to an out-of-bounds write. The assessed impact is primarily availability: a malicious or malformed image-processing operation may crash the ImageMagick process or the application embedding it. The published CVSS vector is local, high-complexity, no privileges required, and no user interaction required, which suggests exploitation depends on a specific reachable processing path and platform behavior rather than being a broadly reliable remote compromise primitive.

Why it matters to the business

Organizations using ImageMagick in upload pipelines, media conversion services, document processing, thumbnail generation, or automation jobs could experience service crashes or failed image-processing workloads if malformed content reaches a vulnerable code path. Because ImageMagick is widely embedded in downstream applications and scripts, exposure may exist indirectly through web applications, CMS platforms, build systems, or backend workers even when ImageMagick is not user-facing. The current public exploitation signal is low: EPSS is 0.00128, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported; however, outages in image-heavy workflows can still have operational impact.

How an attack unfolds

An attacker first needs a way to cause vulnerable ImageMagick code to process attacker-controlled input or to run a local workflow that invokes ImageMagick. In a common service scenario, this could be an image upload, media conversion endpoint, document preview feature, or automated batch job that passes files to ImageMagick utilities or libraries. The attacker provides a specially malformed file or input sequence that reaches the platform-specific error path where the return value is mishandled. The vulnerable code then increments a pointer beyond the end of a stack buffer and performs an out-of-bounds write. The most likely observable result is a crash of the ImageMagick process, worker, or parent service, potentially causing job failures, degraded availability, or repeated denial of service if the input is retried automatically.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-18 or later for the 7.x branch, or 6.9.13-43 or later for the 6.x branch. Where ImageMagick is supplied by an operating-system package manager or container base image, apply the vendor security update and rebuild/redeploy dependent images and applications. Also check applications that bundle ImageMagick or depend on it indirectly through language bindings, media-processing frameworks, CMS plugins, or document-conversion services. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from reaching ImageMagick processing paths, enforcing strict file type and size validation, disabling unnecessary coders/delegates in policy.xml, running ImageMagick in a sandboxed low-privilege worker, applying CPU/memory/time limits, and ensuring failed jobs are not retried indefinitely.

How to confirm the fix worked

Confirm the installed runtime version reports ImageMagick 7.1.2-18 or later, or 6.9.13-43 or later, using package inventory and runtime checks such as `magick -version`, `convert -version`, or vendor package metadata. Validate container images and application build artifacts, not only base hosts, because ImageMagick is often embedded in worker images. Confirm that all image-processing entry points use the upgraded binary or library path and that stale copies are not present in application directories. Review ImageMagick policy.xml to ensure unnecessary coders and delegates are disabled and resource limits are configured. As an exposure test, inventory systems where untrusted uploads, file drops, queues, or APIs can trigger ImageMagick processing and verify they are patched or isolated.

Typical attack path

1. Identify an application, service, script, or batch job that uses ImageMagick to parse or transform images or image-like content.
2. Determine whether the reachable ImageMagick version is older than 7.1.2-18 or 6.9.13-43 and runs on a platform affected by the incorrect return-value behavior.
3. Submit or place a malformed file into the workflow, such as through an upload feature, conversion API, file drop location, or local automation task.
4. Trigger ImageMagick processing through commands such as magick, convert, identify, mogrify, or through an application library binding.
5. Cause the vulnerable stack-buffer pointer arithmetic path to execute, resulting in an out-of-bounds write.
6. Observe process termination, worker restart, failed conversion jobs, core dumps, or service degradation indicating denial of service.

How to detect it

To determine whether exploitation may have occurred, review logs and artifacts from systems that process untrusted images or documents with ImageMagick. Focus on web upload logs, API gateway logs, application worker logs, job queue failures, container restart events, system logs, crash reporting, core dump directories, and endpoint telemetry. Look for bursts of failed image conversions, repeated crashes of `magick`, `convert`, `identify`, or `mogrify`, segmentation faults, stack-buffer or out-of-bounds-write sanitizer findings, abnormal worker restarts, or the same uploaded file repeatedly causing failures. Correlate crash timestamps with upload source IPs, user agents, filenames, file hashes, queue message IDs, and request paths that feed ImageMagick. There are no public, CVE-specific payload strings or known threat-actor indicators for this issue based on the provided intelligence, so detection should emphasize behavioral evidence of attempted denial of service against ImageMagick processing paths.

• segfault.*magick
• segfault.*convert
• segfault.*identify
• segfault.*mogrify
• core dumped.*magick
• core dumped.*convert
• core dumped.*identify
• core dumped.*mogrify
• AddressSanitizer: stack-buffer-overflow
• AddressSanitizer: stack-buffer-overflow.*ImageMagick
• out-of-bounds write.*ImageMagick
• ImageMagick.*Segmentation fault
• MagickCore.*Segmentation fault
• MagickWand.*Segmentation fault

What your security team should do

• Inventory all direct and indirect ImageMagick usage across servers, containers, CI/CD images, media workers, web applications, and document-processing services.
• Prioritize upgrades on systems that process untrusted or externally supplied files, especially internet-facing upload and conversion workflows.
• Upgrade to ImageMagick 7.1.2-18 or later, or 6.9.13-43 or later, and rebuild/redeploy all dependent containers and application packages.
• Add compensating controls for any system that cannot be patched immediately: sandbox execution, low-privilege service accounts, strict input validation, file size limits, resource limits, and reduced ImageMagick coder/delegate policy.
• Monitor for crashes, core dumps, repeated worker restarts, and failed conversions involving ImageMagick utilities after suspicious or malformed uploads.
• Ensure automated job queues quarantine repeatedly failing files instead of endlessly retrying them and amplifying denial-of-service impact.
• Track vendor advisories for operating-system packages and downstream applications that bundle ImageMagick, since fixed package names and backported version strings may differ from upstream release numbers.