CVE-2026-56377

What it actually does

ImageMagick versions before 7.1.2-24 contain an authorization/policy enforcement flaw in path policy checks. A user who can cause ImageMagick to process controlled input or controlled conversion parameters may bypass configured path restrictions and create or truncate files that should have been denied by policy. The primary impact is limited integrity loss: unauthorized file creation, file clobbering, or truncation. The flaw does not directly provide code execution or data disclosure, but it can become more serious if ImageMagick runs with excessive filesystem permissions or writes into locations that influence application behavior, web content, logs, configuration, scheduled jobs, or other trusted processing pipelines.

Why it matters to the business

Organizations using ImageMagick in upload, thumbnailing, document conversion, media processing, or automation workflows could have files unexpectedly created or damaged by a user who can submit conversion jobs. In most deployments this is a contained integrity issue, but impact can increase if the conversion service has write access to sensitive directories, shared volumes, web roots, configuration paths, or operational logs. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploitation indicated, so urgency is lower than actively exploited remote code execution issues; however, internet-facing or multi-tenant conversion services should still prioritize remediation because file-write primitives are commonly chained with other weaknesses.

How an attack unfolds

An attacker first needs a way to influence ImageMagick processing, such as access to a local conversion utility, a web application that accepts uploaded images for conversion, or a backend service that passes user-controlled filenames, formats, or output paths to ImageMagick. The attacker crafts input or conversion parameters that cause ImageMagick to evaluate a path that should be blocked by the configured security policy. Because the affected versions perform an incorrect policy check, the operation may be allowed even though the target path is outside the intended sandbox or denied area. The result is creation or truncation of an attacker-selected file reachable by the ImageMagick process permissions. The attacker may use this to corrupt application state, erase logs, create files in writable web-accessible directories, interfere with batch jobs, or prepare a follow-on attack if another component later trusts or executes the written file.

How to fix it

Upgrade ImageMagick to version 7.1.2-24 or later. Where ImageMagick is supplied by an operating system or container base image, apply the vendor-patched package even if the upstream version string differs. Rebuild and redeploy containers, serverless images, and application bundles that include vulnerable ImageMagick binaries or libraries. In addition to upgrading, run ImageMagick under a dedicated low-privilege account, restrict filesystem access with container isolation, chroot, AppArmor, SELinux, seccomp, or equivalent controls, mount sensitive paths read-only or not at all, use per-job temporary directories, avoid passing user-controlled output paths to ImageMagick, and enforce allowlisted input/output formats. Review policy.xml to ensure dangerous coders, delegates, and path access are restricted, but do not rely on policy configuration alone as the primary fix for this CVE.

How to confirm the fix worked

Confirm the installed version with commands such as `magick -version`, `convert -version`, package-manager inventory, SBOMs, or container image scans, and verify ImageMagick is 7.1.2-24 or a vendor-fixed build. Check all execution contexts, including web workers, background job containers, CI/CD utilities, desktop automation hosts, and third-party application bundles. Validate that the runtime account used by ImageMagick cannot write outside intended temporary/output directories. Perform a benign negative test in a non-production environment by configuring a denied path policy and confirming ImageMagick cannot create or truncate a canary file in that denied location after the upgrade. Review file permissions and mounts to ensure that even a failed policy control would not allow writes to application code, configuration, web roots, logs, credentials, scheduled-task locations, or shared storage.

Typical attack path

1. Identify an application, service, batch job, or API that invokes ImageMagick for image or document processing.
2. Determine whether user-controlled input can influence filenames, output paths, image metadata, pseudo-formats, or conversion options.
3. Submit a crafted file or request intended to make ImageMagick write to a path that should be denied by policy.
4. Rely on the policy-check bypass in vulnerable ImageMagick versions before 7.1.2-24 to create or truncate the chosen file.
5. Use the resulting file creation or truncation to disrupt operations, corrupt application data, alter web-visible content, remove evidence, or chain with another weakness.

How to detect it

To determine whether exploitation already occurred, review application upload logs, API request logs, job-queue records, ImageMagick wrapper logs, web server access logs, EDR telemetry, auditd or Sysmon-style file creation events, container runtime events, and file integrity monitoring. Focus on ImageMagick processes such as `magick`, `convert`, `mogrify`, or application workers invoking ImageMagick that created or truncated files outside expected temporary/output directories. Look for unexpected zero-byte files, recently modified configuration files, overwritten logs, new files in web-accessible directories, and failed or unusual conversion jobs around suspicious upload activity. Pay particular attention to requests containing path traversal patterns, absolute filesystem paths, unusual output filenames, or ImageMagick pseudo-format syntax. Because exploitation may only result in ordinary file creation or truncation and may not generate a unique error, behavioral evidence from process/file telemetry is more reliable than network indicators alone.

• process_name=magick
• process_name=convert
• process_name=mogrify
• process_name=identify
• /usr/bin/magick
• /usr/bin/convert
• /usr/local/bin/magick
• /usr/local/bin/convert
• ImageMagick
• ../
• ..%2f
• ..%2F
• %2e%2e%2f
• %2e%2e/
• policy.xml
• attempt to perform an operation not allowed by the security policy
• not authorized

What your security team should do

• Inventory all systems, containers, and applications that include ImageMagick, especially externally reachable upload, thumbnailing, media conversion, or document rendering services.
• Prioritize upgrades for internet-facing, multi-tenant, or automated conversion services and update to ImageMagick 7.1.2-24 or later, or the relevant vendor-fixed package.
• Rebuild and redeploy container images or application packages that statically bundle ImageMagick rather than relying only on host package updates.
• Harden conversion workers so they run as unprivileged users with write access limited to isolated temporary and output directories.
• Add file integrity monitoring or EDR rules for ImageMagick processes creating or truncating files outside approved conversion directories.
• Review application code to ensure users cannot control arbitrary output paths, filenames with traversal sequences, or dangerous conversion options.
• Preserve and review logs for suspicious conversion errors, unusual output paths, unexpected zero-byte files, or ImageMagick writes to sensitive locations.