CVE-2026-49218

What it actually does

CVE-2026-49218 is an improper input validation flaw in ImageMagick's DCM image decoder. Before ImageMagick 6.9.13-48 and 7.1.2-24, a crafted DICOM/DCM image can be decoded with invalid dimensions because the decoder fails to adequately validate image metadata. Subsequent ImageMagick operations may then crash when handling the malformed in-memory image structure. The impact is availability-only: no confidentiality or integrity impact is described, but unauthenticated remote triggering is possible wherever untrusted images are automatically processed.

Why it matters to the business

Systems that accept or process user-supplied medical imaging or DCM files can be crashed by a malformed image, causing failed uploads, broken image conversion pipelines, interrupted document/media processing, or denial of service in applications that rely on ImageMagick. The CVSS availability impact is high, but current exploitation signals are low: EPSS is 0.00346, it is not listed in CISA KEV, no ransomware use is indicated, and no public exploit maturity is reported. Organizations with internet-facing image upload, conversion, thumbnailing, or medical-image workflows should still prioritize remediation because the vulnerability requires no authentication or user interaction once a malicious file reaches an ImageMagick processing path.

How an attack unfolds

An attacker creates a malformed DCM/DICOM image containing invalid dimension metadata that is not properly rejected by vulnerable ImageMagick versions. The attacker then submits the file to any service, API, mail gateway, content management workflow, document converter, medical imaging pipeline, or batch processor that invokes ImageMagick to identify, convert, resize, thumbnail, or otherwise manipulate the image. When the vulnerable DCM decoder parses the file, it may construct an image object with invalid dimensions. A later operation on that object can crash the ImageMagick process or the parent service, resulting in denial of service. Repeated submissions can sustain outages if workers restart and reprocess the malicious file.

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-24 or later for the 7.x branch. Where ImageMagick is bundled by an operating system, container image, language package, appliance, or application, apply the vendor-provided package update that backports the fix. Rebuild and redeploy containers or serverless artifacts that include vulnerable ImageMagick libraries or binaries. If immediate upgrade is not possible, reduce exposure by disabling DCM/DICOM decoding if not required, rejecting DCM/DICOM uploads from untrusted users, enforcing strict file type allowlists, limiting image dimensions and file sizes before processing, running ImageMagick in a sandboxed/least-privilege worker, applying CPU/memory/time limits, and isolating image-processing queues so crashes do not affect core application availability.

How to confirm the fix worked

Confirm deployed ImageMagick versions report 6.9.13-48 or later, or 7.1.2-24 or later, using commands such as `magick -version`, `convert -version`, or package manager inventory. Validate container and application images as well as host packages because ImageMagick is often embedded in downstream tools. Check ImageMagick policy configuration to confirm DCM/DICOM decoding is disabled if it is not needed. Test upload and processing controls with benign DCM files and oversized or malformed test files in a non-production environment to verify rejection, resource limits, and worker recovery. Confirm that updated workers have been restarted and that stale queued files are not repeatedly processed by older vulnerable components.

Typical attack path

1. Identify an application or service that accepts image uploads or ingests files from untrusted sources.
2. Determine or assume that backend processing uses ImageMagick with DCM/DICOM support enabled.
3. Craft or obtain a malformed DCM file with invalid image dimension metadata.
4. Submit the file through an upload form, API endpoint, message attachment, archive, or automated ingestion workflow.
5. Trigger ImageMagick operations such as identify, convert, resize, thumbnail generation, or metadata extraction.
6. Cause the vulnerable DCM decoder and subsequent image operation to crash the processing worker or service.
7. Repeat submissions or leave the file in an automated processing queue to prolong denial of service.

How to detect it

Look for evidence of suspicious DCM/DICOM file ingestion followed by ImageMagick crashes or worker restarts. Relevant sources include web and API upload logs, object storage access logs, mail or file-ingestion gateway logs, application conversion logs, job queue records, container logs, systemd/journald, kernel logs, crash dumps, and endpoint telemetry for ImageMagick processes. Hunt for repeated uploads of `.dcm` or DICOM-like files from the same source, failed thumbnail or conversion jobs, sudden increases in HTTP 5xx responses around image processing endpoints, and process crashes involving `magick`, `convert`, `identify`, or libraries used by ImageMagick. Because no public exploit indicators or actor-specific tradecraft are reported, detection should focus on behavioral correlation: untrusted DCM input immediately preceding crashes, segmentation faults, aborts, out-of-memory events, or repeated worker restarts.

• .dcm
• DCM
• DICOM
• magick
• convert
• identify
• ImageMagick
• Segmentation fault
• segfault
• core dumped
• Aborted
• panic:
• worker restart
• failed to process image
• failed to decode DCM
• no decode delegate for this image format
• improper image header
• invalid image dimensions
• cache resources exhausted
• memory allocation failed

What your security team should do

• Inventory all systems, containers, applications, and third-party products that include or invoke ImageMagick, especially internet-facing upload and conversion services.
• Prioritize upgrades to ImageMagick 6.9.13-48 or later, or 7.1.2-24 or later, on services that process untrusted files.
• If patching cannot be completed quickly, temporarily block or quarantine DCM/DICOM files unless the business explicitly requires them.
• Apply file size, dimension, timeout, memory, and process isolation controls around all ImageMagick execution paths.
• Search logs and queues for DCM/DICOM files submitted shortly before ImageMagick worker crashes or repeated processing failures.
• Add monitoring for abnormal ImageMagick process exits, worker restarts, segmentation faults, and spikes in failed image conversions.
• Rebuild base images and redeploy workloads after package updates to ensure vulnerable binaries are not retained in containers or artifacts.
• Track upstream and operating-system advisories for backported fixed package versions if exact distro package versions differ from upstream ImageMagick release numbers.