Software Engineering Institute

Overview

Multiple arbitrary file read and write vulnerabilities have been identified in applications that use ImageMagick with insufficiently restrictive security policies. Collectively referred to as ImageTragick2, these issues arise when ImageMagick processes attacker-controlled SVG or PostScript content using dangerous coders or delegates permitted by its default or application-supplied configuration. An attacker who can upload an image, or otherwise cause an application to process crafted image content, may be able to read or write files accessible to the ImageMagick process. In some deployments, these capabilities may be chained to achieve arbitrary code execution, compromising the confidentiality, integrity, and availability of the affected application and host.

Description

ImageMagick is a widely used open-source image-processing suite. Web and content-management applications, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, may use ImageMagick for operations such as thumbnail generation, cropping, conversion, and transformation. ImageMagick is also commonly included in containerized AI image-processing pipelines. It may operate before inference to normalize or transform inputs, or after inference to convert and prepare generated output. In these environments, images may originate not only from direct uploads but also from URLs, automated agents, datasets, model outputs, or other upstream services.

Two vulnerability variants have been identified:
Coder invocation through SVG (MSL injection)

ImageMagick's SVG processing can allow a crafted SVG <image> element to invoke a dangerous coder through its xlink:href value, for example, by referencing an MSL: resource. ImageMagick may then interpret the referenced content as a Magick Scripting Language (MSL) script. The script can invoke additional image readers and direct attacker-controlled image data to selected filesystem paths, enabling unauthorized file access. Exploitation depends on the internal SVG coder and the required dangerous coders being available to the ImageMagick process.

Ghostscript invocation through content detection

ImageMagick's content-based format detection may identify crafted input as PostScript and invoke Ghostscript, a separate interpreter used by ImageMagick to handle PostScript, EPS, and PDF, even when the filename or declared type suggests another format. Although Ghostscript is invoked with -dSAFER, the observed configuration permits file access within /tmp. A crafted PostScript file may therefore read or write data in that directory. This can affect applications that use shared temporary storage for uploaded files, processing artifacts, sessions, or other security-sensitive data.

These issues highlight an important aspect of ImageMagick's security model: Behavior that can be restricted through a custom security policy is treated as a configuration issue, not a vulnerability in ImageMagick itself. Applications and distributions are therefore responsible for deploying a policy appropriate to their threat model. Many integrations, however, process untrusted content without a sufficiently restrictive policy.

Impact

An attacker who can cause an affected application to process crafted SVG or PostScript content may be able to read or write files in directory locations accessible to the ImageMagick process. In some cases, arbitrary code execution is possible when file access can be combined with writable executable content. AI-enabled services that utilize ImageMagick may face additional exposure because of untrusted image processing. In container deployments, writable host mounts, shared volumes, credentials, or inference artifacts can substantially increase the impact of a successful exploit.

Solution

Consult the Vendor Information section for product-specific updates and mitigations. Users of products that integrate ImageMagick, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, should install vendor-provided updates when available. Updating ImageMagick alone may be insufficient if its security policy continues to permit dangerous coders or delegates.

Apply a custom policy.xml based on an allowlist: enable only the formats and operations the application requires, and disable unnecessary coders and delegates, including MSL, MVG, PS, EPS, and PDF. ImageMagick's bundled secure policy template may not be sufficient for every deployment; verify the effective policy and confirm that prohibited formats are rejected.

Additional recommendations include:
- Isolate image processing: Process untrusted images in a dedicated, minimally privileged environment with restricted filesystem access. Apply the same controls to AI preprocessing and post-processing pipelines.
- Validate and constrain input: Verify file content rather than relying on filenames, extensions, or client-supplied media types.
- Monitor processing activity: Alert on ImageMagick policy violations, unexpected delegate or coder use, unusual processing failures, and unexpected file creation.

Acknowledgements

Thanks to RyotaK of GMO Flatt Security Inc. for reporting these vulnerabilities. The pwn.ai team independently discovered Variant 2 and reported it to WordPress as CVE-2026-65640. This document was written by Vijay Sarvepalli and Molly Jaconski.

Vendor Information

References

• https://imagemagick.org/script/security-policy.php
• https://www.hacktron.ai/blog/hacking-openai
• https://github.com/rails/rails/security/advisories/GHSA-f3w6-w445-fwh9