CVE-2026-34238

What it actually does

An integer overflow in ImageMagick's despeckle image-processing operation can cause an undersized heap allocation on 32-bit builds. When the operation continues, ImageMagick may write past the end of the heap buffer, causing memory corruption. The most likely practical impact is process crash and denial of service; reliable code execution is not indicated by the provided data and exploitation complexity is high. The issue affects ImageMagick versions before 6.9.13-44 and 7.1.2-19.

Why it matters to the business

Systems that process untrusted images with ImageMagick, especially upload pipelines, media-processing workers, document conversion services, and automation using 32-bit builds, can be crashed by a specially crafted image if the despeckle operation is invoked. This can interrupt image conversion, queue processing, web application functionality, or batch jobs. The vulnerability is not listed in CISA KEV, has no known exploit maturity, and has very low, flat EPSS, so urgency is moderate unless ImageMagick is exposed to untrusted file processing at scale.

How an attack unfolds

An attacker prepares an image designed to trigger the integer overflow when ImageMagick performs the despeckle operation on a 32-bit build. The attacker then causes the target workflow to process that file, such as by submitting it to an image upload, conversion, thumbnailing, or batch-processing path that applies despeckling. During processing, the overflow leads to an out-of-bounds heap write. In typical scenarios this corrupts process memory and terminates the ImageMagick process or the worker invoking it, causing failed conversions, repeated job retries, service degradation, or denial of service. Exploitation depends on the target actually using a vulnerable 32-bit ImageMagick version and invoking the affected operation.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-44 or later for the 6.x branch, or 7.1.2-19 or later for the 7.x branch. If ImageMagick is supplied by an operating-system package, apply the vendor security update and confirm whether the vendor backported the fix even if the displayed upstream version appears older. Prioritize remediation for 32-bit deployments and any service that processes untrusted images. Where immediate upgrade is not possible, reduce exposure by disabling or removing workflows that apply despeckle to untrusted files, running image processing in isolated containers or sandboxes with strict CPU, memory, and restart limits, limiting accepted image dimensions and file sizes, and ensuring workers run with least privilege. Prefer 64-bit supported builds, but do not treat architecture change as a substitute for applying the fixed version.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `convert -version`, or the relevant package manager query, and verify it is 6.9.13-44 or later, 7.1.2-19 or later, or a vendor-patched build containing the fix. Inventory both command-line binaries and linked libraries used by applications, containers, serverless functions, and batch workers. Validate whether any 32-bit ImageMagick packages or images remain in use. Review image-processing configuration and application code for despeckle usage. After patching, run normal image-processing regression tests and confirm workers no longer crash or produce segmentation faults when handling malformed or unusual images. In containerized environments, rebuild and redeploy images rather than only updating the base host.

Typical attack path

1. Identify an application, job, or service that processes attacker-supplied images using ImageMagick.
2. Determine or assume that the workflow applies the despeckle operation directly or through a preset image-processing pipeline.
3. Submit a crafted image intended to trigger the integer overflow on a vulnerable 32-bit ImageMagick build.
4. Wait for the conversion or image-processing worker to invoke the vulnerable despeckle code path.
5. Cause heap memory corruption, usually resulting in an ImageMagick crash, failed processing job, or service disruption.
6. Repeat submissions if the goal is sustained denial of service against processing queues or worker pools.

How to detect it

To determine whether this was already exploited, review logs from applications that invoke ImageMagick, upload services, media-processing queues, container platforms, endpoint telemetry, and operating-system crash logs. Focus on 32-bit ImageMagick processes that crashed while handling user-supplied images or while applying despeckle. Useful sources include web upload logs, job queue failure records, worker stderr/stdout, systemd journal, kernel logs, core dump records, EDR process telemetry, container restart events, and application exception logs. Look for repeated crashes of `magick`, `convert`, or ImageMagick-linked workers shortly after image uploads; command lines or logs containing `-despeckle`; segmentation faults; heap-buffer-overflow reports from hardened or instrumented builds; and recurring malformed image submissions from the same source. There are no known public exploit indicators, threat actors, KEV activity, or ransomware use provided, so detection should be behavior-based rather than relying on hashes or fixed network signatures.

• -despeckle
• despeckle
• magick
• convert
• ImageMagick
• DespeckleImage
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• out of bounds write
• Segmentation fault
• SIGSEGV
• segfault at
• core dumped
• systemd-coredump
• Process: magick
• Process: convert

What your security team should do

• Inventory all ImageMagick installations, including embedded copies in containers, application bundles, CI/CD images, and media-processing workers.
• Prioritize upgrades for internet-facing or partner-facing image upload and conversion workflows, especially any running 32-bit builds.
• Upgrade to ImageMagick 6.9.13-44 or later, 7.1.2-19 or later, or the applicable vendor-patched package.
• Search application code, scripts, and processing profiles for despeckle usage and disable it for untrusted input until patched if upgrade cannot be completed quickly.
• Enforce sandboxing, resource limits, file size limits, and worker isolation around ImageMagick processing of untrusted files.
• Monitor for ImageMagick crashes, core dumps, container restarts, failed conversion spikes, and repeated submissions of images that trigger processing failures.
• Because EPSS is very low and there is no KEV listing or known exploit maturity, handle through standard vulnerability remediation unless the affected processing path is externally reachable or business-critical.