ImageMagick's Security Boundary Is the Effective Policy, Not the Upload Filename
ImageMagick's Security Boundary Is the Effective Policy, Not the Upload Filename ImageMagick is often described as an image converter even though it can invoke coders and external delegates for many formats. CERT/CC pu
ImageMagick's Security Boundary Is the Effective Policy, Not the Upload Filename
ImageMagick is often described as an image converter even though it can invoke coders and external delegates for many formats. CERT/CC published VU#580079 on 2026-11-12 for applications that process attacker-controlled SVG or PostScript with an insufficiently restrictive policy. The report calls the collection ImageTragick2.
The advisory treats the behavior as a configuration issue. Updating ImageMagick without changing the effective policy may leave the application exposed.
Two paths into file access
The first variant uses SVG processing to invoke a dangerous coder. A crafted SVG <image> element can use xlink:href to reference an MSL: resource. ImageMagick may interpret that resource as a Magick Scripting Language script, read additional images and write attacker-controlled data to selected filesystem paths. Exploitation depends on the internal SVG coder and the required coders being available.
The second variant abuses content-based format detection. Crafted input can be identified as PostScript even when the filename or declared type suggests another format. ImageMagick invokes Ghostscript for PostScript, EPS and PDF. Although Ghostscript runs with -dSAFER, the observed configuration allowed access within /tmp. A crafted file can read or write data there.
Shared temporary storage matters because applications often place uploads, processing artifacts, session data and other sensitive files in the same directory tree. File write can become code execution when the process can overwrite executable content or when another component later loads the modified file.
Who is affected
The note names web and content applications, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic and Redmine, as examples of integrations that may call ImageMagick for thumbnails, crops, conversions and transformations. Containerized AI pipelines may also use it before or after inference.
Not every integration is vulnerable. The application must process attacker-controlled content and permit a dangerous coder or delegate. The effective policy, filesystem permissions and the origin of the input determine the path. A file that arrives through a URL, automated agent, dataset or model output may still be attacker-controlled.
Remediation
Apply vendor updates for the integrating application. Ruby on Rails shipped 8.0.5.2 and 8.1.4.1 with a policy.xml for Active Storage's use of mini_magick. Updates to ImageMagick alone may not change a permissive policy.
Use an allowlist policy that enables only required formats and operations. Disable unnecessary coders and delegates, including MSL, MVG, PS, EPS and PDF. Verify that a prohibited format is rejected by the deployed process rather than assuming a template file was loaded.
Isolate image processing in a dedicated environment with minimal filesystem access. Validate content rather than relying on filename extensions or client-supplied media types. Monitor policy violations, unexpected delegate use and file creation in processing directories.
Verification
Run a test file through the same container, service account and configuration used in production. Confirm that the dangerous formats are rejected before Ghostscript or MSL processing occurs. Check temporary directories and mounted volumes for write access that would turn a parser issue into broader host impact.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.