CVE-2026-48733

What it actually does

The vulnerability is an availability flaw in ImageMagick's subimage-search functionality. When ImageMagick processes a specially crafted image using the affected operation, it can enter an infinite loop and consume CPU indefinitely or until the process is terminated. The issue does not directly enable code execution, data theft, or file modification, but it can cause denial of service in applications, batch jobs, worker queues, or services that invoke ImageMagick on attacker-supplied or untrusted images. Exploitation requires the vulnerable image-processing path to be reached, typically through user interaction or an application workflow that accepts and processes the crafted image.

Why it matters to the business

Systems that process uploaded, emailed, or otherwise untrusted images with ImageMagick may experience stuck conversion jobs, exhausted worker capacity, high CPU utilization, delayed image-processing queues, and service degradation. The CVSS score is moderate and EPSS is currently very low, and it is not listed in CISA KEV or known ransomware use, but ImageMagick is widely embedded in web applications, CMS platforms, media pipelines, CI jobs, and backend automation, so operational impact can be broad where image processing is exposed to untrusted content.

How an attack unfolds

An attacker prepares an image file designed to trigger the infinite loop in ImageMagick's subimage-search operation. The attacker then causes a vulnerable application, service, or user workflow to process that file with ImageMagick prior to versions 6.9.13-49 or 7.1.2-24. If the vulnerable code path is invoked, the ImageMagick process may hang in a loop, consuming CPU and tying up a worker process or request handler. Repeated submissions can multiply the effect, filling processing queues or exhausting compute resources. Because the weakness is denial-of-service only, the attack goal is disruption rather than persistence or data access.

How to fix it

Upgrade ImageMagick to a patched release: 6.9.13-49 or later for the 6.x branch, or 7.1.2-24 or later for the 7.x branch. Ensure fixes are applied not only to operating-system packages but also to container images, application bundles, language-specific wrappers, static builds, and third-party appliances that ship their own ImageMagick binaries. Where immediate upgrade is not possible, reduce exposure by disabling or avoiding subimage-search on untrusted input, enforcing strict CPU and wall-clock timeouts around ImageMagick commands, limiting worker concurrency, using sandboxing or resource policies, and rejecting or quarantining untrusted image formats that are not required for business operations.

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 is at least 6.9.13-49 or 7.1.2-24 depending on the deployed branch. Check container images and embedded binaries separately because they may differ from the host package version. Review application code and job definitions for use of subimage-search or wrapper libraries that call it. After patching, run representative image-processing workflows under CPU and timeout monitoring to confirm jobs complete normally and do not hang. Validate operational controls by confirming ImageMagick processes are subject to resource limits, execution timeouts, and queue backpressure controls.

Typical attack path

1. Identify an application, service, script, or workflow that accepts image files and processes them with ImageMagick.
2. Determine whether the image-processing flow invokes or can reach subimage-search functionality on attacker-controlled input.
3. Create or obtain a crafted image that triggers the infinite loop in vulnerable ImageMagick versions.
4. Submit the image through an upload form, API, email attachment, shared folder, batch feed, or other ingestion path.
5. Wait for the backend process to invoke ImageMagick on the crafted file.
6. Repeat submissions if necessary to consume worker capacity, CPU time, or processing queue slots and degrade service availability.

How to detect it

To determine whether this was already exploited, review application upload logs, API gateway logs, web server logs, batch ingestion records, and media-processing job logs for image submissions followed by ImageMagick processes that ran unusually long, timed out, or consumed excessive CPU. Correlate timestamps of failed or stalled image jobs with process telemetry from EDR, systemd journals, container logs, Kubernetes events, and scheduler or queue systems. Look for repeated invocations of ImageMagick commands using subimage-search, frequent worker restarts, job timeout messages, or bursts of uploads from the same source immediately before CPU saturation. Preserve suspicious uploaded image files for offline analysis in an isolated environment; do not reprocess them on unpatched systems. There are no reliable universal file hashes or network signatures for the crafted images, so detection should focus on process behavior, command-line arguments, job duration anomalies, and repeated failures tied to image-processing workflows.

• subimage-search
• -subimage-search
• magick compare
• compare -subimage-search
• convert -subimage-search
• ImageMagick
• CPU time limit exceeded
• process timed out
• job timed out
• worker timeout
• operation timed out
• killed after timeout

What your security team should do

• Inventory all production, staging, CI, container, and appliance locations where ImageMagick is installed or bundled.
• Prioritize patching internet-facing or externally fed image-processing services, especially upload pipelines and asynchronous media workers.
• Upgrade to ImageMagick 6.9.13-49 or later, or 7.1.2-24 or later, and rebuild dependent containers or application images.
• Add execution timeouts, CPU limits, memory limits, and worker isolation for all ImageMagick invocations that process untrusted files.
• Search application code, scripts, and job definitions for subimage-search usage and restrict it to trusted inputs where possible.
• Monitor for repeated long-running or CPU-bound ImageMagick processes, especially following image uploads or batch ingestion events.
• Because this issue is not in KEV, has no known public exploit maturity, and has very low EPSS, treat it as a patching and hardening priority rather than an emergency unless exposed image-processing workloads are business-critical.