WordPress has released version 7.0.4, a security-focused update that closes a remote code execution vulnerability affecting sites that process images with the Imagick extension and Ghostscript.
The WordPress security team is urging site owners to update immediately, either through the Dashboard’s Updates screen or by downloading the release directly from WordPress.org, since sites with automatic background updates should already be receiving the patch.
The flaw, tracked as CVE-2026-65640 and detailed in GHSA-8vr3-7mxf-gx8w, was responsibly disclosed by researchers at pwn.ai and allows an authenticated Author-level user to achieve remote code execution through a crafted file upload.
The issue arises from WordPress’s reliance on ImageMagick to resize and process Media Library images. ImageMagick doesn’t stop at JPEGs and PNGs; it also opens PostScript, EPS, and PDF files, and to render those formats it hands the work off to Ghostscript, a tool with a long history of being tricked into executing unintended commands.
WordPress Imagick RCE Vulnerability
Security researchers will recognize this as the same family of bugs behind the notorious “ImageTragick” vulnerabilities from years past.
The core problem was a mismatch in how files get identified. ImageMagick determines a file’s type by reading its actual contents, while WordPress’s WP_Image_Editor_Imagick::load() method was largely trusting the file extension instead.
That meant a file named something innocent like holiday.png could actually contain PostScript code, sail past upload checks, and still get handed to Imagick, which would recognize the embedded PostScript and invoke Ghostscript to execute it.
Normally, WordPress’s wp_check_filetype_and_ext() function catches this kind of mismatch during standard uploads, but not every upload path runs through that check.
XML-RPC’s wp.uploadFile method and the cover-art extraction routine for uploaded MP3 files both write bytes directly using wp_upload_bits(), which skips content inspection entirely, giving attackers an alternate route to plant a malicious payload.
The fix, shipped in commit 7daaa50, rewrites the load() function so it inspects a file’s actual content before ever constructing an Imagick object.
It now scans the first chunk of every uploaded file and blocks anything bearing PostScript or EPS signatures, fake PDFs that claim the extension but lack the genuine %PDF- header, and compressed files like gzip or bzip2 that ImageMagick would otherwise silently unpack.
The patch also closes a sneakier trick where attackers could prefix a filename with a format specifier, such as EPS:innocent.png, to force ImageMagick toward the dangerous decoder; the new code strips and validates these prefixes while carefully avoiding false positives on Windows drive letters, and applies the same scrutiny to filenames arriving via remote URLs or streams.
Exploitation requires Author-level access or higher, so this isn’t a drive-by, unauthenticated attack. That said, the real-world risk depends heavily on who holds accounts on a given site.
Multi-author publications, membership platforms, and client sites with open or loosely managed contributor access face genuine exposure, since any Author can attempt to upload a booby-trapped file disguised as an image. Sites limited to a small, trusted editorial team carry comparatively low risk.
According to WordPress, the fixes are being backported through the 4.7 branch and into the upcoming 7.1 RC3 release, though only the latest WordPress version receives full ongoing support. Site administrators should verify their version and update without delay, particularly on sites where upload privileges extend beyond a core trusted team.
[Live Webinar] Join Elastic & UnderDefense to learn how small security teams can unify AI visibility and agentic response into one operating model -> Register Now
The post Critical WordPress RCE Vulnerability Allows Authors to Execute Code via Malicious PNG File appeared first on Cyber Security News.
