CVE-2026-62946

What it actually does

ImageMagick versions before 6.9.13-52 and 7.1.2-27 contain an integer overflow in JNX image handling on 32-bit platforms. When ImageMagick parses an extremely large JNX file, size calculations can wrap, causing allocation of an undersized heap buffer followed by a heap buffer overwrite. The most likely technical result is process crash and denial of service for software that automatically processes uploaded, received, or batch-converted images. The available scoring indicates no expected confidentiality or integrity impact, although heap overwrite flaws should still be treated cautiously in exposed automated processing pipelines.

Why it matters to the business

Organizations using ImageMagick in 32-bit environments or embedded 32-bit image-processing components may experience service disruption if a malicious or malformed JNX file is processed. This can affect web upload workflows, document/image conversion services, media pipelines, ticketing systems, archival systems, and any application that invokes ImageMagick automatically. The public exploitation likelihood is currently low, with low EPSS, no known KEV listing, and no reported exploit maturity, but the issue is newly published and should be remediated during normal vulnerability maintenance, with higher priority where untrusted image files are processed automatically.

How an attack unfolds

An attacker prepares a specially crafted, extremely large JNX file designed to trigger an integer overflow during ImageMagick's size or offset calculations on a 32-bit platform. The attacker then gets a vulnerable system to process the file, for example by uploading it to an application that generates previews, submitting it to an automated media conversion workflow, or placing it where a batch processing job will run ImageMagick against it. During parsing, the overflow causes ImageMagick to allocate or reference an incorrect heap buffer size, and subsequent parsing writes past the end of that buffer. In practical terms, this is expected to crash the ImageMagick process or the calling worker, causing denial of service for that conversion task or, if repeatedly triggered, for the dependent service.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-52 or later for the 6.x branch, or 7.1.2-27 or later for the 7.x branch. Where packages are provided by an operating system or container base image, apply the vendor-supplied security update and rebuild/redeploy dependent images or appliances. Give priority to 32-bit deployments and any service that processes untrusted files. If immediate upgrade is not possible, mitigate by blocking or disabling JNX processing where feasible, rejecting unusually large JNX files before they reach ImageMagick, enforcing strict upload size limits, running image conversion in isolated low-privilege sandboxes, applying process memory and CPU limits, and ensuring worker crashes do not take down the parent service.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `convert -version`, or package-manager queries, and verify it reports 6.9.13-52 or later, or 7.1.2-27 or later. Confirm whether the runtime is 32-bit, because the described overflow condition is specific to 32-bit platforms. Inventory applications and containers that bundle ImageMagick separately from the host operating system. Validate that JNX files and oversized uploads are either safely processed by the patched version or rejected by policy. Review CI/CD images, serverless layers, appliance firmware, and embedded distributions for stale ImageMagick binaries.

Typical attack path

1. Identify an application, service, or workflow that uses ImageMagick to process user-supplied or externally sourced files.
2. Determine or assume that the processing component is running a vulnerable ImageMagick release before 6.9.13-52 or 7.1.2-27 on a 32-bit platform.
3. Create an oversized or malformed JNX image file that triggers the vulnerable integer overflow path.
4. Submit the crafted JNX file through an upload, ingestion, email attachment, file drop, API, or batch-processing path.
5. Wait for ImageMagick or a dependent service to parse the file automatically.
6. Trigger a heap buffer overwrite that causes the image-processing process or worker to crash, degrading availability.

How to detect it

Look for evidence that ImageMagick processed suspicious JNX files shortly before crashes or service restarts. Useful sources include application upload logs, reverse proxy logs, image conversion job logs, worker supervisor logs, container logs, Linux system logs, crash dumps, core dump metadata, and endpoint telemetry showing ImageMagick command execution. Search for unusually large files with `.jnx` extensions, repeated conversion failures, segmentation faults, heap corruption messages, worker restarts, and abnormal exits from `magick`, `convert`, `identify`, or application-specific image conversion workers. On Linux, review `journalctl`, `/var/log/syslog`, `/var/log/messages`, kernel logs, apport/abrt/systemd-coredump records, and container orchestrator restart events. If memory sanitizers or hardened allocators are present, look for heap-buffer-overflow, malloc corruption, or invalid write messages associated with JNX parsing. Correlate timestamps of crashes with inbound uploads, API requests, email attachments, or file ingestion events containing `.jnx` filenames or `image/x-jnx`-like metadata.

• .jnx
• JNX
• magick
• convert
• identify
• Segmentation fault
• segfault at
• heap-buffer-overflow
• heap buffer overflow
• heap-buffer-overwrite
• invalid write
• malloc(): corrupted top size
• malloc(): memory corruption
• corrupted double-linked list
• double free or corruption
• free(): invalid next size
• AddressSanitizer: heap-buffer-overflow
• ImageMagick
• systemd-coredump
• Process: magick
• Process: convert
• Process: identify
• /usr/bin/magick
• /usr/bin/convert
• /usr/bin/identify
• /usr/local/bin/magick
• /usr/local/bin/convert
• /usr/local/bin/identify

What your security team should do

• Inventory ImageMagick usage across servers, containers, appliances, CI/CD images, and application dependencies, with emphasis on services that process untrusted uploads or attachments.
• Prioritize patching 32-bit systems and externally reachable or automated image-processing workflows to ImageMagick 6.9.13-52, 7.1.2-27, or later.
• If patching is delayed, temporarily block JNX files and enforce conservative file-size limits before files reach ImageMagick.
• Run ImageMagick in a restricted sandbox with least privilege, resource limits, and worker isolation to reduce denial-of-service blast radius.
• Monitor for crashes, segmentation faults, abnormal worker restarts, and repeated processing of large `.jnx` files.
• Rebuild and redeploy container images or packaged applications that statically bundle vulnerable ImageMagick versions.
• Track vendor advisories for downstream packages because operating system package versions may include backported fixes without matching upstream version numbers.