CVE-2026-46559

What it actually does

This flaw is a memory corruption issue in ImageMagick's JP2/JPEG 2000 image handling. Prior to ImageMagick 6.9.13-48 and 7.1.2-23, an incorrect bounds check can allow a one-byte heap buffer overwrite when JP2 processing is invoked with certain options. The most likely technical result is a crash of the ImageMagick process, causing a low-impact availability issue for image conversion or metadata-processing workflows. There is no public evidence from the provided data of reliable code execution, data disclosure, or active exploitation.

Why it matters to the business

Organizations that use ImageMagick to process images may experience failed image uploads, broken thumbnail generation, interrupted media workflows, or crashes in background processing jobs if crafted JP2/JPEG 2000 files are processed. The business risk is highest for internet-facing applications or automated pipelines that accept untrusted image files. Overall urgency is moderate to low because the CVSS score is 4.0, EPSS is very low, it is not listed in CISA KEV, it is not associated with ransomware use, and no mature exploit is reported; however, patching should still be prioritized where ImageMagick handles user-supplied media.

How an attack unfolds

An attacker first needs a path for a crafted JP2/JPEG 2000 image to be processed by a vulnerable ImageMagick installation, or local ability to invoke ImageMagick directly. The attacker prepares a malformed JP2 file and triggers processing with the option set that reaches the faulty bounds check. When the vulnerable JP2 code path is exercised, ImageMagick performs a one-byte heap overwrite. In practical terms, this is expected to terminate or destabilize the ImageMagick process, which can disrupt image processing services, job queues, or upload workflows. In server-side use cases, the attacker may not need shell access if an application automatically passes uploaded images to ImageMagick, but exploitation still depends on the application using the affected JP2 functionality and relevant options.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-48 or later for the 6.x branch, or 7.1.2-23 or later for the 7.x branch. Use vendor-supported packages from the operating system distribution, container base image, language runtime image, or upstream ImageMagick release channel. Rebuild containers and redeploy applications that bundle ImageMagick statically or include it in their runtime image. If immediate patching is not possible, reduce exposure by blocking or disabling JP2/JPEG 2000 processing for untrusted files, restricting accepted upload formats, applying file type validation before conversion, running ImageMagick in a sandboxed low-privilege context, and enforcing resource limits for image-processing workers.

How to confirm the fix worked

Confirm the installed version using commands such as `magick -version`, `convert -version`, or package-manager queries, and verify it reports ImageMagick 6.9.13-48, 7.1.2-23, or a later vendor-backported fixed build. Validate container images and build artifacts as well as host packages, because applications often ship their own ImageMagick binaries. Test that JP2/JPEG 2000 processing still works as expected after upgrade, or confirm that JP2/JPEG 2000 input is rejected if mitigation blocks that format. Review software composition inventory and vulnerability scanner results to ensure no older ImageMagick binaries remain in application images, worker nodes, CI/CD images, or batch-processing environments.

Typical attack path

1. Identify an application, service, job worker, or local workflow that uses ImageMagick to process JP2/JPEG 2000 images.
2. Determine whether the ImageMagick version is older than 6.9.13-48 or 7.1.2-23.
3. Craft or obtain a malformed JP2/JPEG 2000 image designed to trigger the faulty JP2 option-handling path.
4. Submit the file through an upload feature, media import path, batch processing workflow, or local command invocation.
5. Cause ImageMagick to parse the file with the vulnerable JP2 options.
6. Trigger a one-byte heap overwrite, likely resulting in a process crash or failed image-processing job.

How to detect it

To determine whether this issue may already have been triggered, review application upload logs, image-conversion job logs, worker logs, system logs, container logs, EDR telemetry, and crash reporting systems for failures involving JP2/JPEG 2000 files processed by ImageMagick. Focus on unexplained segmentation faults, aborts, heap corruption messages, repeated worker restarts, failed thumbnail or conversion jobs, and errors occurring immediately after processing files with `.jp2`, `.j2k`, `.jpf`, `.jpx`, or JPEG 2000 MIME types. Correlate crashes of `magick`, `convert`, `identify`, or application-specific image workers with inbound uploads or batch-import events. Because no public exploit indicators or unique payload patterns are provided, detection should be behavior-based rather than signature-based. Preserve suspicious input files, command-line arguments, crash dumps, and container logs for forensic review before cleanup or redeployment.

What your security team should do

• Inventory systems, containers, and applications that include ImageMagick, especially media upload, thumbnailing, document conversion, and batch image-processing services.
• Prioritize upgrades for systems that process untrusted user-supplied images or expose image conversion through web applications or APIs.
• Upgrade to ImageMagick 6.9.13-48, 7.1.2-23, or later, including rebuilt containers and redeployed worker images.
• If patching is delayed, temporarily block JP2/JPEG 2000 uploads or disable JP2/JPEG 2000 processing in exposed workflows.
• Run ImageMagick with least privilege, filesystem isolation, resource limits, and sandboxing to reduce the impact of future parser vulnerabilities.
• Monitor for repeated crashes of `magick`, `convert`, `identify`, or image-processing workers associated with JP2/JPEG 2000 inputs.
• Treat this as lower urgency than actively exploited or KEV-listed vulnerabilities, but include it in the next normal patch cycle unless untrusted JP2 processing is exposed.