A single uploaded .jpg or .pdf file can achieve file writes to /tmp/ on default ImageMagick installations across major Linux distributions. The vulnerabilities bypass the default open security policy, the recommended production "limited" policy, and on systems where GhostScript is compiled as a linked library, even the most restrictive "secure" policy.
While the write destination is constrained to /tmp/ by GhostScript's -dSAFER sandbox, this is far from harmless. The researchers demonstrated that /tmp/ writes can be chained into session poisoning, RAM exhaustion denial-of-service, and further code execution depending on the target application.
These findings, published by pwn.ai, represent one of the most thorough dismantlings of a widely deployed security architecture we have seen this year. The research deserves close attention from any organization that processes user-uploaded images.
"This is the kind of research that should make security teams stop and check their assumptions," says Melvin Lammerts, Head of Hacking & Solutions at Hadrian. "ImageMagick is one of those dependencies that sits so deep in the stack that most teams forget it is there. It processes images behind WordPress, behind internal tools, behind customer-facing upload forms. And what this research shows is that every policy layer designed to make that safe was broken."
Extension-based upload filtering does not work
The first foundational issue is widely underappreciated: ImageMagick does not rely on file extensions to determine how a file should be processed. It inspects the file's content and uses magic byte detection to select the appropriate processing coder.
A file named photo.jpg that begins with <?xml at byte zero will be processed as SVG, regardless of the .jpg extension. The researchers confirmed this across thirteen different file extensions.
Adnan, Hacker at Hadrian, points to this as the detail that elevates the research beyond a typical vulnerability report. "A lot of teams think they are safe because they only accept .jpg or .png uploads. But ImageMagick ignores the extension entirely. It reads the first few bytes and decides for itself what format it is looking at. That single behavior invalidates most upload filtering logic I see in production."
From file read to file write in a single upload
The researchers chained multiple gaps to escalate from information disclosure to file write.
The first link was an arbitrary file read. An SVG payload disguised as a .jpg, referencing the internal text: coder, causes the content of any server-readable file to be rendered as visible text in the output image. Server secrets, environment variables (including AWS credentials stored in /proc/self/environ), SSH keys, and .env files all become accessible through a single upload.
The escalation to file write required bypassing ImageMagick's policy enforcement. Ubuntu's default policy blocks PostScript and EPS processing. However, several PostScript-adjacent coders (EPSI, EPI, EPSF) were not included in the blocklist despite invoking the same GhostScript delegate. A further detection bypass was achieved by prepending a single newline byte to a PostScript payload, which prevented ImageMagick from detecting the file as PostScript while GhostScript still executed it normally.
Under GhostScript 9.55.0's -dSAFER mode (the version shipping on Ubuntu 22.04), shell execution via %pipe% is blocked, but PostScript file I/O operations to /tmp/ remain permitted. The researchers demonstrated writing attacker-controlled content to /tmp/ through this path.
Every policy layer was broken
What sets this research apart is the methodical escalation through every available mitigation.
The "limited" policy, recommended for production environments, blocks the PS module but not the PDF module. Both invoke GhostScript through the same delegate. A PostScript payload with a .pdf extension bypassed the limited policy entirely.
The researchers then discovered the EPT format (Encapsulated PostScript with TIFF preview). EPT is registered as its own module, is absent from every policy blocklist, and is detected purely by magic bytes regardless of file extension. A single .jpg file with the right magic bytes achieves file write on the limited policy. This specific bypass affects ImageMagick versions up to 6.9.13-33, which includes the version shipping on Ubuntu 22.04 (6.9.11-60). It was silently fixed in 6.9.13-34 without a CVE.
Even the "secure" policy was bypassed on systems where GhostScript is compiled as a linked library rather than an external binary. Amazon Linux ships this configuration by default. The secure policy only intercepts external process invocations. When GhostScript runs in-process via a library call, the policy check never fires. The PDF bypass and the gslib delegate bypass remain unfixed in all versions, including the latest.
"What stands out is the persistence of the approach," says Adnan. "They broke the default policy, then the recommended policy, then the maintainer's own suggested fix, then the most restrictive policy. Each time a mitigation was applied, they found the next gap. That is exactly how a determined attacker operates."
WordPress and Ubuntu 22.04 are directly exposed
WordPress uses ImageMagick (via the PHP Imagick extension) as its default image processing engine when available, and sets no ImageMagick security policy of its own. The researchers confirmed on WordPress 6.9.4 that an Author-level user (the minimum role that can upload files) can achieve file write through a single upload. Combined with Gravity Forms (2M+ active installations), the attack becomes pre-authentication: an unauthenticated visitor can submit a crafted .jpg through a public form and trigger GhostScript execution.
Ubuntu 22.04 LTS, one of the most widely deployed server operating systems, ships a particularly exposed combination: ImageMagick 6.9.11-60 and GhostScript 9.55.0. The EPT bypass was silently fixed in a later ImageMagick release without a CVE and without being backported. Default WordPress installations on Ubuntu 22.04 with ImageMagick remain vulnerable to the EPT bypass. Ubuntu 22.04 has standard support until April 2027.
Proof of Concept
We reproduced the findings independently in a Docker container running Ubuntu 22.04 with ImageMagick 6.9.11-60 and vanilla GhostScript 9.55.0, the exact versions described in the research.
The file read required a single command:
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
ImageMagick identified read.jpg as SVG and rendered /etc/passwd into the output image. The .jpg extension was ignored entirely. We confirmed this across all thirteen tested extensions every one was detected as SVG when the content began with <?xml.
The PDF file write confirmed on both open and limited policies:
printf '\n%%!PS-Adobe-3.0 EPSF-3.0\n%%%%BoundingBox: 0 0 100 100
\n/f (/tmp/PWNED) (w) file def\nf (HADRIAN) writestring
\nf closefile\nshowpage\n' > evil.pdf
convert evil.pdf out.png
cat /tmp/PWNED
# Output: HADRIAN
The limited policy blocks PS but not PDF. Both invoke the same GhostScript binary. A single .pdf bypasses the recommended production hardening.
We also confirmed the EPSI coder bypass: GhostScript was invoked despite PS and EPS being blocked, and achieved file write to /tmp/ through a two-file SVG chain.
One nuance worth noting: Ubuntu's packaged GhostScript 9.55.0 has received thirteen rounds of backported security patches that harden -dSAFER and block /tmp/ writes. The vanilla 9.55.0 build does not. Organizations running GhostScript from source or on non-Ubuntu distributions should assume the /tmp/ write primitive is available.
What to do now
Organizations processing untrusted images through ImageMagick should assess their exposure. If GhostScript is installed alongside ImageMagick, it should be removed unless there is a specific operational requirement. If PDF processing is needed, it should be isolated in a sandboxed environment with no network access and a read-only filesystem.
For WordPress deployments, the server's policy.xml must be manually configured to block all GhostScript-invoking modules, since WordPress itself sets no restrictions. XML-RPC should be disabled if not required. Teams should also check whether their ImageMagick installation is compiled with gslib by running convert --version. If gslib appears in the delegates list, the secure policy's delegate blocking is non-functional.
The full technical details, proof-of-concept examples, and a policy bypass matrix are available in pwn.ai's original research.
Why this keeps happening
These vulnerabilities exist in fully patched, properly configured systems. There is no CVE for most of the findings, recommended policies are applied, and software is up to date, yet the system is still exploitable.
"This is a textbook example of why you cannot rely on configuration and policy alone to manage risk," says Melvin. "Every stack has dependencies like this: widely trusted, rarely audited, processing untrusted input. The question is whether you find these exposures through adversarial testing before they matter, or whether you learn about them from a blog post after they have been sitting in production for years."
The gap between what a security policy is designed to prevent and what it actually prevents in practice can only be measured by testing the real attack paths an adversary would follow. Point-in-time assessments and CVE-based patching are not enough when the vulnerabilities live in architectural assumptions rather than missing patches.
To learn how Hadrian helps organizations identify and validate real-world exposures across their attack surface, book a demo.
