CVE-2026-40310

What it actually does

ImageMagick versions before 7.1.2-19 and 6.9.13-44 contain a heap out-of-bounds write in the JP2 encoder when an invalid sampling index is supplied. The most likely technical outcome is process memory corruption leading to a crash or abnormal termination during JP2/JPEG 2000 encoding. Based on the published CVSS vector, the assessed impact is denial of service rather than confirmed data disclosure or code execution.

Why it matters to the business

Systems that use ImageMagick to process user-supplied images can experience failed conversions, worker crashes, service instability, or processing backlogs if malformed JP2-related input reaches vulnerable code paths. The current public exploitation signal is low: EPSS is approximately 0.0019, unchanged over 30 days, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. However, ImageMagick is commonly embedded in web applications, content pipelines, CMS platforms, document processors, and containerized workloads, so exposure may be indirect through downstream software rather than obvious standalone installations.

How an attack unfolds

An attacker first needs a workflow that invokes ImageMagick’s JP2 encoder, such as an image conversion, thumbnailing, media ingestion, or batch processing pipeline. The attacker then causes ImageMagick to encode JP2 content while supplying or influencing an invalid sampling index. On vulnerable versions, the encoder writes outside the bounds of heap memory, corrupting process memory. In practical terms, this is expected to crash the ImageMagick process or the application worker that embeds it, causing denial of service for image-processing functionality. There is currently no public evidence that this issue is being exploited in the wild or used by named threat actors.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-19 or later for the 7.x branch, or 6.9.13-44 or later for the 6.x branch. Where ImageMagick is supplied by an operating-system distribution, install the vendor security update even if the displayed upstream version appears older, because distributions may backport the fix. Rebuild and redeploy container images, language bindings, application bundles, serverless layers, and appliances that include ImageMagick or link against vulnerable ImageMagick libraries. If immediate patching is not possible, reduce exposure by disabling JP2/JPEG 2000 encoding in ImageMagick policy configuration where not required, restricting accepted output formats, validating conversion options, sandboxing image-processing workers, applying CPU/memory/time limits, and isolating image-processing services from critical application components.

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 7.1.2-19 or later, 6.9.13-44 or later, or a vendor package that explicitly includes the backported fix. Check all runtime locations, including containers, build images, CI runners, application dependencies, and embedded appliances, because multiple ImageMagick versions may coexist. Validate that applications are actually using the patched binary or library by checking runtime paths and container layers. If JP2 support is not required, confirm policy restrictions prevent JP2/JPEG 2000 encoding. After patching, monitor conversion jobs for continued crashes or abnormal restarts to ensure the vulnerable code path is no longer reachable.

Typical attack path

1. Identify an application, service, job, or endpoint that uses ImageMagick for image processing.
2. Determine whether the workflow can trigger JP2/JPEG 2000 encoding rather than only decoding or resizing to other formats.
3. Submit or cause processing of crafted image data or conversion parameters that result in an invalid sampling index being used by the JP2 encoder.
4. Trigger ImageMagick on a vulnerable version prior to 7.1.2-19 or 6.9.13-44.
5. Cause heap memory corruption, typically resulting in a crash, failed conversion, restarted worker, or degraded image-processing availability.

How to detect it

There are no public, reliable indicators of active exploitation for this issue at this time. To assess whether exploitation may have occurred, review application upload logs, image-conversion job logs, worker stderr/stdout, system logs, container runtime events, EDR crash telemetry, and core dump records for crashes of ImageMagick processes such as `magick`, `convert`, or applications embedding ImageMagick libraries. Focus on events involving JP2/JPEG 2000 output formats, especially `.jp2`, `.j2k`, `.j2c`, `.jpf`, or `.jpx`, followed by segmentation faults, heap corruption messages, abnormal exits, container restarts, or repeated failed conversion attempts. Correlate suspicious image-processing failures with web access logs, API requests, message-queue jobs, or batch submissions from the same source around the crash time. Because benign malformed files can also trigger crashes, treat findings as suspicious only when there is a pattern of repeated attempts, external untrusted input, unusual JP2 conversion requests, or close timing between submitted files and worker failures.

What your security team should do

• Inventory ImageMagick usage across servers, containers, developer tooling, CI/CD images, web applications, media-processing services, and third-party products that bundle it.
• Prioritize patching internet-facing or user-input-driven image-processing workflows, even though current exploitation likelihood is low.
• Upgrade to ImageMagick 7.1.2-19 or later, 6.9.13-44 or later, or the appropriate vendor-backported package.
• Temporarily disable JP2/JPEG 2000 encoding if it is not business-critical, especially in upload, conversion, and thumbnailing services.
• Run image-processing workloads with least privilege, filesystem isolation, resource limits, and crash containment so a malformed file cannot disrupt broader services.
• Review recent logs for ImageMagick crashes, worker restarts, failed JP2 conversions, or bursts of JP2/J2K inputs followed by service instability.
• Ensure container images and application bundles are rebuilt after the package update rather than only updating base hosts.