CVE-2026-55510

What it actually does

ImageMagick versions before 6.9.13-51 and 7.1.2-26 contain a use-after-free flaw in handling a crafted 8BIM image profile during image identification. When a vulnerable ImageMagick component such as identify, convert, magick, or a linked library processes a malicious image containing the triggering profile and format string, memory that has already been freed can be accessed. Based on the published scoring, the expected impact is process crash and denial of service rather than confirmed data disclosure or code execution.

Why it matters to the business

Systems that automatically inspect, resize, convert, or validate user-supplied images may be disrupted by a malicious file, causing failed image processing jobs, degraded media workflows, queue backlogs, service instability, or application-level denial of service. The issue is not listed in CISA KEV, has low EPSS, and has no public exploit maturity reported, so broad exploitation urgency is lower than for internet-wormable flaws; however, any service that accepts untrusted image uploads should still prioritize patching because exploitation only requires getting the vulnerable processor to open the crafted file.

How an attack unfolds

An attacker creates or obtains an image file containing a specially crafted 8BIM profile with a format string that triggers the vulnerable memory handling path in ImageMagick. The attacker then causes a vulnerable workflow to identify or process the image, for example by uploading it to an application, attaching it to a ticket or message, placing it in a watched processing directory, or convincing a user/operator to run ImageMagick tooling against it. When ImageMagick parses the profile, the use-after-free condition occurs and the processing process may crash. In automated environments, repeated submissions can repeatedly kill workers or exhaust processing capacity, resulting in denial of service for image-related features.

How to fix it

Upgrade ImageMagick to a fixed release: 6.9.13-51 or later for the 6.x branch, or 7.1.2-26 or later for the 7.x branch. Ensure applications that bundle ImageMagick or link against MagickCore/MagickWand are rebuilt or redeployed against the fixed library. Where immediate upgrading is not possible, reduce exposure by rejecting or quarantining untrusted image uploads, limiting supported image formats and profiles where feasible, processing images in isolated sandboxed workers, enforcing CPU/memory/time limits, disabling unnecessary coders/delegates via policy.xml, and preventing repeated crash loops from taking down the broader application.

How to confirm the fix worked

Confirm the installed runtime version with commands such as `magick -version`, `convert -version`, or `identify -version`, and verify it reports ImageMagick 6.9.13-51 or later, or 7.1.2-26 or later. Check package manager metadata and container images to ensure the patched library is present in every runtime image, not only on build hosts. For applications that bundle ImageMagick, verify the application artifact or container has been rebuilt after the library upgrade. Validate operational resilience by processing representative benign images and confirming image identification/conversion jobs complete normally without crashes. If security testing uses a controlled proof-of-concept sample, run it only in an isolated test environment and confirm the patched version no longer crashes.

Typical attack path

1. Identify a target application or workflow that uses ImageMagick to inspect, identify, convert, thumbnail, or otherwise process images.
2. Craft an image containing a malformed 8BIM profile with the triggering format-string condition.
3. Deliver the image through an upload form, API endpoint, email attachment, shared file location, or other path that reaches ImageMagick processing.
4. Trigger image identification or conversion on a vulnerable ImageMagick version prior to 6.9.13-51 or 7.1.2-26.
5. Cause the ImageMagick process or dependent worker to crash, potentially repeating the delivery to sustain service disruption.

How to detect it

Look for evidence of repeated ImageMagick process crashes or failed image-identification/conversion jobs shortly after image uploads, attachments, or file ingestion events. Useful log sources include application upload logs, media-processing worker logs, job queue failure records, container orchestrator restart events, systemd or init service logs, kernel crash logs, core dump records, EDR process telemetry, and web/API access logs for image-upload endpoints. Correlate crashes of `magick`, `identify`, `convert`, or applications linked to MagickCore/MagickWand with recently processed files containing 8BIM metadata. In forensic review, preserve the triggering image files and inspect them in a safe offline environment for 8BIM profile data; do not reprocess suspicious files on production systems. There are no widely published attacker-specific indicators, threat actors, ransomware campaigns, or stable network signatures for this issue as described, so detection should focus on behavioral evidence of crashes and repeated malformed image submissions.

What your security team should do

• Inventory services, containers, batch jobs, and third-party applications that use ImageMagick, especially those processing untrusted uploads or attachments.
• Prioritize upgrades on internet-facing upload paths, media-processing queues, document-conversion services, and any automated workflow that invokes ImageMagick on files from external users.
• Upgrade to ImageMagick 6.9.13-51 or later, or 7.1.2-26 or later, and rebuild dependent images/applications that statically bundle or dynamically link ImageMagick libraries.
• Add resource limits, sandboxing, and worker isolation around image-processing tasks to reduce the blast radius of future parser crashes.
• Monitor for repeated ImageMagick crashes, unusual spikes in failed image-processing jobs, and repeated uploads of files containing 8BIM profiles from the same source.
• Because this is not currently KEV-listed and has low EPSS, treat it as a targeted hardening and reliability fix unless local exposure includes high-volume untrusted image ingestion.