WordPress Imagick RCE (CVE-2026-65640): What Site Owners Need to Know

WordPress has just released a security-focused update — version 7.0.4 — to close a remote code execution flaw that can be triggered when images are processed with the Imagick extension and Ghostscript. The vulnerability, tracked as CVE-2026-65640 and described in GHSA-8vr3-7mxf-gx8w, was responsibly disclosed by researchers at pwn.ai. While exploitation requires an authenticated Author-level account or higher, the bug’s mechanics mean multi-author sites, membership platforms, and installations with broad contributor access are particularly exposed. Site owners should understand how the issue works, why some upload paths bypass protections, and what fixes and mitigations to apply immediately.

How the vulnerability works

At its core the problem stems from a mismatch between how WordPress and ImageMagick identify file types. ImageMagick inspects file contents and can accept a range of formats — including PostScript, EPS, and PDF — and delegates rendering of some of those formats to Ghostscript. WordPress’s WP_Image_Editor_Imagick::load() method previously relied too heavily on file extensions instead of verifying the actual file content. That allowed a file named holiday.png to contain PostScript or another unexpected payload that ImageMagick would detect and hand to Ghostscript, which in turn could be tricked into executing unintended commands. This class of bug echoes the earlier “ImageTragick” incidents that exploited how ImageMagick handled embedded formats.

Upload paths that bypass checks

WordPress normally uses wp_check_filetype_and_ext() to verify that the file’s declared type matches its contents during the standard media upload flow. However, not all upload routines run through that check. The XML-RPC wp.uploadFile method and WordPress’s cover-art extraction for uploaded MP3s write bytes directly with wp_upload_bits(), skipping the content inspection layer. Those alternative paths provided ways to plant a crafted file that looked like an image at first glance but contained hostile PostScript or other payloads that would later trigger Ghostscript via Imagick processing.

What the patch changes

WordPress shipped a fix in commit 7daaa50 that significantly hardens the Imagick load routine. The updated load() now inspects the initial bytes of uploaded files before constructing an Imagick object. It blocks files that bear PostScript or EPS signatures, detects fake PDFs that lack the genuine “%PDF-” header, and prevents compressed archives (gzip, bzip2) from being silently unpacked by ImageMagick. The patch also strips and validates format-prefixes in filenames (e.g., EPS:innocent.png) that could force ImageMagick into a dangerous decoder, while carefully avoiding false positives like Windows drive-letter prefixes. The fix is being backported to the 4.7 branch and applied across actively supported versions; WordPress 7.1 RC3 will include it as well.

Who is really at risk

Exploitation requires an Author-level account or greater, so this is not a fully unauthenticated, drive-by remote code execution. Nevertheless, risk is real for sites where multiple people can upload media or where contributor onboarding is loose. Large editorial publications, membership sites with community uploads, and client installs allowing external contributors are most vulnerable. Single-author or tightly controlled sites face lower risk, though they should not be complacent if any editorial accounts are shared or third-party users have upload privileges.

Immediate mitigation steps

Update WordPress now to 7.0.4 or later, or apply the provided patches if you maintain older supported branches. Sites with automatic background updates should receive the fix automatically, but administrators should verify the version.
Audit user roles and reduce upload privileges where possible. Remove or limit Author-level rights for accounts that do not require them.
Disable XML-RPC if you do not use it; many attacks and legacy upload paths rely on it.
Review any plugins or custom code that call wp_upload_bits() or otherwise handle uploads outside standard media flows; ensure they validate file contents.
If feasible, restrict or sandbox Ghostscript/ImageMagick on the server so that even if a crafted file is encountered, the processing environment is constrained.

Longer-term recommendations

Beyond the immediate patch, administrators and developers should take a layered approach to file-upload security. Implement server-side content inspection independent of file extensions, use antivirus or malware scanning for uploaded files, and consider processing untrusted uploads in isolated worker containers. Keep server packages (ImageMagick, Ghostscript) up to date, and monitor vendor advisories for related CVEs. Finally, review user-access policies and require multi-factor authentication for privileged accounts to limit the impact of compromised credentials.

Closing thoughts

CVE-2026-65640 is a reminder that the intersection of content handling libraries and web-application upload logic is a recurring source of risk. The WordPress team’s fix addresses the immediate attack vectors by enforcing content inspection and stripping dangerous filename tricks, but site owners must act quickly to update and harden upload paths. A small operational change — tightening who can upload and how uploads are processed — can make the difference between a routine update and a destructive compromise.