CVE-2026-56379

What it actually does

ImageMagick's SVG decoder can be coerced into interpreting attacker-supplied content as Magick Vector Graphics commands during image rendering. When an affected ImageMagick version processes a crafted SVG, injected MVG directives may execute inside the ImageMagick rendering pipeline, allowing the attacker to alter rendering behavior and potentially trigger dangerous file, URL, delegate, or command-handling paths depending on local ImageMagick policy and enabled coders/delegates. The primary exposure is any server-side workflow that automatically runs ImageMagick against untrusted SVG files, such as upload validation, thumbnail generation, document conversion, preview generation, or media processing queues.

Why it matters to the business

A vulnerable image-processing workflow can turn a routine SVG upload or conversion request into an attacker-controlled execution path. This may lead to service disruption, unauthorized access to local or remote resources reachable by the image-processing service, compromise of generated content, and in higher-risk configurations possible command execution under the privileges of the ImageMagick process. ImageMagick is widely embedded in web platforms, CMS plugins, CI jobs, media pipelines, and downstream libraries, so exposure may exist indirectly even where ImageMagick is not a primary application component. The issue is not currently listed in CISA KEV and the provided EPSS score is low, but the attack surface is common and the exploit precondition is simple: processing an attacker-controlled SVG.

How an attack unfolds

An attacker identifies an application or service that accepts SVG files or retrieves attacker-controlled SVG content for conversion, inspection, resizing, previewing, or thumbnailing. The attacker crafts an SVG containing content that escapes or abuses the SVG-to-MVG decoding path so that arbitrary MVG drawing commands are interpreted by ImageMagick. The file is then uploaded, submitted, or made available to the target workflow. When an affected ImageMagick version before 7.1.2-15 or 6.9.13-40 processes the SVG using commands such as magick, convert, identify, or mogrify, the injected MVG commands execute as part of rendering. Depending on ImageMagick policy.xml, enabled coders, delegate configuration, network access, filesystem permissions, and sandboxing, the attacker may be able to cause unexpected file or URL access, invoke unsafe delegates, manipulate output, exhaust resources, or potentially achieve command execution in the image-processing context.

How to fix it

Upgrade ImageMagick to a fixed release: 7.1.2-15 or later for the 7.x branch, and 6.9.13-40 or later for the 6.x branch. Because ImageMagick is often installed through operating-system packages or bundled into containers, rebuild container images and redeploy workloads after the package update. If immediate upgrade is not possible, disable or block SVG processing for untrusted files, convert SVGs in a hardened isolated sandbox, and enforce a restrictive ImageMagick policy.xml. At minimum, disable risky coders and delegates that are not required, restrict external URL/file access, apply resource limits for memory, CPU, time, map, disk, and dimensions, and run image conversion under a dedicated low-privilege account with no write access outside temporary processing directories. Validate MIME type and file content, but do not rely on extension checks alone. Where SVG support is not business-critical, reject SVG uploads entirely or rasterize them with a safer isolated renderer.

How to confirm the fix worked

Confirm the runtime ImageMagick version on all servers, containers, build images, worker nodes, and media-processing jobs using commands such as `magick -version`, `convert -version`, or package-manager inventory. Verify that versions are ImageMagick 7.1.2-15 or later, or 6.9.13-40 or later. Check that application containers were rebuilt after patching rather than only updating a base image. Review ImageMagick policy.xml to ensure unnecessary SVG/MVG-related coders, external URL handlers, file access, and delegates are disabled or tightly constrained. Test representative upload and conversion paths with benign SVGs to confirm expected functionality, and with a controlled security test file that exercises SVG parsing without executing harmful actions to confirm suspicious MVG constructs are rejected or safely contained. Validate that the image-processing service runs as a non-privileged user, has egress restrictions, and cannot write outside designated temporary/output paths.

Typical attack path

1. Find an application feature that accepts SVG uploads, imports remote images, generates thumbnails, converts documents, or previews user-supplied media.
2. Confirm or infer that the backend uses ImageMagick for SVG parsing or rendering.
3. Create a malicious SVG that injects MVG drawing commands into the SVG decoder path.
4. Submit the SVG through an upload, API request, import job, email attachment, CMS asset, or queued media-processing workflow.
5. Wait for the vulnerable ImageMagick process to render or inspect the file.
6. Leverage the injected MVG behavior to access resources, invoke unsafe processing paths, manipulate output, or escalate to command execution where local policy permits.
7. Clean up or blend activity into normal image-processing logs and temporary ImageMagick artifacts.

How to detect it

Review evidence from web upload logs, API gateway logs, object-storage access logs, media-processing queue logs, application worker logs, ImageMagick error/debug logs, EDR telemetry, process creation events, DNS logs, proxy logs, and firewall egress logs. Look for SVG uploads or conversion requests followed by ImageMagick processes such as magick, convert, identify, or mogrify behaving unusually, including spawning shells or delegate utilities, making outbound network connections, reading unexpected local files, writing outside normal output directories, crashing repeatedly, or consuming excessive CPU/memory. Search stored SVGs and request bodies, where available, for embedded MVG syntax, protocol handlers, external image references, and suspicious escaping around SVG attributes. On Linux systems, review temporary directories for ImageMagick artifacts created around suspicious upload times, commonly named magick-* or delegates launched from temporary paths. Because no specific public campaign indicators are provided, treat the listed indicators as hunting leads rather than proof of compromise; correlate them with timestamps, source IPs, user accounts, uploaded filenames, process ancestry, and outbound connections.

• magick
• convert
• identify
• mogrify
• /tmp/magick-
• magick-*
• push graphic-context
• pop graphic-context
• image over
• mvg:
• MVG
• file://
• https://
• http://
• caption:@
• label:@
• ephemeral:
• msl:
• svg:
• unable to open image
• not authorized
• delegate failed
• no decode delegate for this image format

What your security team should do

• Inventory all direct and indirect ImageMagick usage, including web upload handlers, CMS plugins, media workers, CI pipelines, document conversion services, and container images.
• Prioritize patching any internet-facing or unauthenticated workflow that processes user-controlled SVGs.
• Upgrade to ImageMagick 7.1.2-15 or later, or 6.9.13-40 or later, and redeploy rebuilt artifacts.
• Temporarily block SVG uploads or route them to an isolated conversion sandbox until patching is complete.
• Harden ImageMagick policy.xml to disable unnecessary coders, delegates, external resource access, and risky file protocols.
• Add EDR and SIEM monitoring for unexpected child processes, network connections, and filesystem access initiated by ImageMagick processes.
• Search historical upload stores, queues, and logs for SVG files containing suspicious MVG directives or external resource references.
• Apply OS-level sandboxing, seccomp/AppArmor/SELinux profiles, resource limits, and egress controls to image-processing workloads.