CVE-2026-40183

What it actually does

ImageMagick versions before 7.1.2-19 contain a heap-based write overflow in the JPEG XL (JXL) encoder when an image is encoded using 16-bit floating-point output. A local user or an application workflow that invokes ImageMagick on attacker-influenced content can trigger memory corruption during JXL encoding. The assessed impact is primarily availability: the ImageMagick process may crash or be terminated, potentially disrupting image-processing pipelines. The published CVSS vector indicates local attack conditions, no privileges required, and user interaction required, with no confirmed confidentiality or integrity impact.

Why it matters to the business

Organizations that use ImageMagick for image conversion, thumbnailing, media processing, document handling, or automated asset pipelines could experience service disruption if vulnerable versions process crafted input through the affected JXL encoding path. Internet-facing upload services are only materially exposed if they convert user-controlled content to JPEG XL with 16-bit float settings. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so urgency is lower than for actively exploited remote code execution flaws; however, affected systems should still be upgraded because ImageMagick is commonly embedded in downstream applications and processing workflows.

How an attack unfolds

An attacker first identifies a workflow that uses ImageMagick below version 7.1.2-19 and causes images to be encoded as JPEG XL with 16-bit floating-point output. The attacker then supplies or induces processing of image content through that conversion path, such as by uploading a file to an application, submitting media to a batch processor, or convincing a user to run a conversion locally. When ImageMagick reaches the vulnerable JXL encoder code path, the malformed or triggering conversion parameters cause a heap write overflow. In practical terms, the expected outcome is a crash of the ImageMagick process or its parent job, which can interrupt image processing, cause failed uploads, break media pipelines, or create repeated denial-of-service conditions if the workflow automatically retries the same input.

How to fix it

Upgrade ImageMagick to version 7.1.2-19 or later wherever ImageMagick is installed directly or bundled inside container images, application packages, build agents, media workers, CI jobs, or desktop tooling. If vendor packages have backported the fix without using the upstream version number, verify the distribution advisory rather than relying only on the displayed upstream version. If immediate upgrade is not possible, reduce exposure by disabling JPEG XL encoding support where feasible, blocking conversion to JXL, preventing untrusted users from controlling output format or bit-depth options, and isolating ImageMagick processing in sandboxed, resource-limited workers. Apply CPU, memory, timeout, and retry limits to image-processing jobs to reduce denial-of-service impact from crashes or repeated triggering inputs.

How to confirm the fix worked

Confirm the installed ImageMagick version is 7.1.2-19 or later using commands such as `magick -version`, `convert -version`, or the relevant operating-system package manager. Validate container images and statically bundled application artifacts as well as host packages. Check whether JXL support is enabled with `magick -list format` or `identify -list format` and review any workflows that output `.jxl` files or use JPEG XL conversion settings. After patching, run representative JXL conversions using the same application options, including 16-bit float paths if used operationally, and confirm the process completes without crashes, segmentation faults, sanitizer findings, or core dumps. For mitigations, confirm untrusted users cannot request JXL output or 16-bit float encoding and that processing workers enforce memory and execution-time limits.

Typical attack path

1. Find an application, script, service, or user workflow that invokes ImageMagick for image conversion.
2. Confirm or infer that the installed ImageMagick version is older than 7.1.2-19 and includes JPEG XL encoding support.
3. Identify whether the workflow encodes images to JXL using 16-bit floating-point output or can be made to do so through options, presets, or file handling logic.
4. Submit or persuade processing of attacker-controlled image content through that conversion path.
5. Trigger the vulnerable JXL encoder heap write overflow during conversion.
6. Cause the ImageMagick process, worker, batch job, or dependent service to crash, resulting in denial of service or failed processing.

How to detect it

To determine whether this was already exploited or accidentally triggered, review application logs, image-processing worker logs, batch job logs, operating-system crash logs, container logs, and core-dump records for ImageMagick crashes during JPEG XL encoding. Focus on events involving `magick`, `convert`, or other ImageMagick-linked processes that occur immediately after processing user-submitted images or producing `.jxl` output. Look for segmentation faults, aborts, heap corruption messages, sanitizer findings, worker restarts, repeated job failures, and unusually high retry rates for the same image input. On Linux systems, inspect `journalctl`, `systemd-coredump`, `/var/log/syslog`, `/var/log/messages`, container runtime logs, and application queue failure logs. If AddressSanitizer or hardened allocator logging is enabled, search for heap-buffer-overflow or heap corruption reports referencing the JXL encoder or ImageMagick coders. Because there are no public reports of active exploitation and no unique attacker payload is published, detection should be behavior-based rather than signature-only.

• magick
• convert
• identify
• magick: abort
• convert: abort
• Segmentation fault
• Segmentation fault (core dumped)
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• heap corruption
• corrupted size vs. prev_size
• double free or corruption
• malloc(): corrupted top size
• systemd-coredump
• ImageMagick
• coders/jxl
• JXL
• JPEG XL
• .jxl
• image/jxl
• 16-bit float
• 16 bit floats

What your security team should do

• Inventory ImageMagick installations across servers, containers, developer workstations, CI/CD runners, media workers, and third-party application bundles.
• Prioritize upgrading systems that process user-supplied files or automated high-volume media workloads, even though current exploitation likelihood is low.
• Upgrade ImageMagick to 7.1.2-19 or later, or apply the vendor backport that explicitly fixes this JXL encoder heap overflow.
• If patching is delayed, disable or block JXL output and prevent untrusted input from controlling encoder options, especially 16-bit floating-point output.
• Harden image-processing services with sandboxing, least privilege, memory limits, CPU limits, job timeouts, and bounded retry behavior.
• Search logs and crash telemetry for recent ImageMagick crashes involving JXL conversion, 16-bit float settings, heap overflows, or segmentation faults.
• Add regression tests for image-conversion workflows that use JPEG XL to ensure future upgrades do not reintroduce unsafe processing paths.