CVE-2026-42326

What it actually does

ImageMagick versions prior to 6.9.13-47 and 7.1.2-22 contain a memory-safety flaw in the code path used when writing IPTC output. A specially crafted input image can cause ImageMagick to read one byte outside the intended memory boundary. The most likely technical outcomes are process crash or limited unintended memory disclosure from the ImageMagick process. There is no indication from the provided data that this enables code execution, privilege escalation, or direct file modification.

Why it matters to the business

Systems that automatically process untrusted images could experience failed image-conversion jobs, service instability, or limited exposure of process memory. The risk is moderate because exploitation requires a crafted file and the known impact is limited, but ImageMagick is widely embedded in web applications, document workflows, content-management systems, media pipelines, and package dependencies, so exposure may exist indirectly through software that invokes ImageMagick. EPSS is low and stable, the issue is not in CISA KEV, and no public exploit maturity is reported, so remediation should be scheduled promptly rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker prepares a malformed image designed to trigger the IPTC-writing code path in vulnerable ImageMagick versions. The attacker then gets the target system to process that file, for example by uploading it to an application, submitting it to a media conversion workflow, sending it through a document-ingestion pipeline, or otherwise placing it where ImageMagick will convert or write IPTC metadata. When the vulnerable process handles the file and writes IPTC output, it reads one byte beyond the intended buffer. Depending on runtime conditions, this may cause the ImageMagick process or calling service to crash, fail the conversion task, or expose a very small amount of adjacent process memory. There are no currently identified threat actors, KEV listing, ransomware linkage, or mature public exploit reports in the provided intelligence.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-47 or later for the 6.x branch, or 7.1.2-22 or later for the 7.x branch. Where ImageMagick is bundled by an operating system, container image, language package, or third-party application, apply the relevant vendor update and rebuild/redeploy dependent images and services. If immediate patching is not possible, reduce exposure by preventing untrusted users from submitting files to ImageMagick workflows, disabling unnecessary IPTC metadata handling where feasible, enforcing strict file type and size validation before processing, running ImageMagick under a low-privilege account, applying sandboxing or container isolation, and using resource limits to reduce denial-of-service impact.

How to confirm the fix worked

Confirm the installed ImageMagick version with commands such as `magick -version`, `convert -version`, or package-manager inventory, and verify it is at least 6.9.13-47 or 7.1.2-22 depending on the deployed branch. Check container images, CI build images, application bundles, and indirect dependencies, not only host packages. Validate that applications using ImageMagick have been restarted or redeployed after upgrade. For exposure testing, review whether externally supplied image files can reach ImageMagick conversion or IPTC metadata-writing paths. If a safe vendor-provided regression test or proof-of-concept becomes available, run it only in a controlled non-production environment and confirm the patched version no longer crashes or reports an out-of-bounds read under memory-safety instrumentation.

Typical attack path

1. Identify an application, service, or workflow that uses ImageMagick to process uploaded or externally supplied images.
2. Craft or obtain an image file that triggers the vulnerable IPTC output-writing behavior.
3. Submit the file through an upload form, API, email/document ingestion flow, shared storage location, or other path that causes ImageMagick to process it.
4. Trigger conversion, metadata extraction, or output generation involving IPTC data.
5. Observe a crash, conversion failure, service disruption, or potentially limited memory disclosure from the ImageMagick process.

How to detect it

To determine whether exploitation may already have occurred, review logs from applications and services that invoke ImageMagick, especially upload handlers, media converters, content-management systems, document-processing queues, and batch image pipelines. Look for repeated failures or crashes immediately after processing externally supplied image files, especially operations involving IPTC metadata or conversion to IPTC output. Relevant log sources include web/API access logs, application error logs, worker queue logs, container stdout/stderr, systemd journal, crash dumps, core files, EDR process telemetry, and kernel logs for segmentation faults. Investigate suspicious sequences where a user or source IP uploads an image and the ImageMagick, `magick`, or `convert` process exits abnormally. Memory-safety instrumented environments may show AddressSanitizer or similar out-of-bounds read findings. Because the bug is a one-byte out-of-bounds read and no unique exploit artifact is provided, reliable detection depends on correlating crafted image submissions with ImageMagick crashes, conversion errors, or sanitizer reports rather than matching a single definitive IOC.

• magick
• convert
• identify
• composite
• mogrify
• montage
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• AddressSanitizer: stack-buffer-overflow
• AddressSanitizer: SEGV
• out-of-bounds read
• heap-buffer-overflow
• buffer over-read
• Segmentation fault
• segfault at
• core dumped
• IPTC
• iptc

What your security team should do

• Inventory all direct and bundled ImageMagick installations across servers, containers, CI/CD images, desktop tooling, and applications that process uploaded media.
• Prioritize upgrades for internet-facing upload, media-processing, document-conversion, and content-management workflows that accept untrusted files.
• Upgrade to ImageMagick 6.9.13-47 or later, or 7.1.2-22 or later, and redeploy any dependent services or container images.
• Apply compensating controls until patched: file validation, sandboxed processing, least-privilege execution, resource limits, and restricted access to image-processing endpoints.
• Monitor application and system logs for unusual ImageMagick crashes, repeated conversion failures, or sanitizer reports associated with image uploads or IPTC metadata processing.
• Track vendor advisories for downstream packages and operating-system backports because package versions may differ from upstream ImageMagick numbering.
• Given the low and stable EPSS, no KEV status, no ransomware association, and no known exploit maturity, handle as a normal vulnerability-management priority unless local exposure includes high-volume untrusted image processing.