WordPress 7.0.4 patches Imagick flaw that lets authors run code

WordPress 7.0.4 patches a flaw that let a logged-in author turn an ordinary looking image upload into code running on the server. Patchstack, the security company that reported the issue, published its write-up on 12 August 2026 and says the problem affects WordPress core versions 4.7 through 7.0. WordPress.org has published its own announcement of the release. Patchstack also says it deployed a mitigation rule to affected websites connected to its platform.

WordPress relies on ImageMagick, a widely used image processing toolkit that it reaches through a PHP extension called Imagick, to resize and process the pictures in the Media Library. The catch is that ImageMagick understands far more than JPEG and PNG images. It can also open PostScript, EPS and PDF files, and to render those formats it calls out to Ghostscript, a separate program with a long history of being talked into running commands it should not. Patchstack places this in the same family of problems as the older ImageTragick bugs.

The mismatch that created the risk comes down to how each side decides what a file is. ImageMagick identifies a file by its contents, while WordPress was mostly trusting the file name extension. A file named holiday.png that actually contained PostScript would therefore clear the upload checks and be handed to Imagick, which would recognise the PostScript inside it and start Ghostscript. The picture was never a picture.

Patchstack traces the flaw to the load() method in WP_Image_Editor_Imagick, the part of WordPress that hands an uploaded file to the image library. It chose how to pass the file along based only on the extension and never looked inside the file. The readImage() and readImageBlob() calls used there inspect the file's identifying bytes, the so-called magic bytes, and ignore the name. Content beginning with %!, \x04%!, \xC5\xD0\xD3\xC6 or \xFFWPC is enough to select ImageMagick's PostScript, EPS or WordPerfect graphics handling, and from there Ghostscript executes the file as a PostScript program.

In an ordinary upload, WordPress's wp_check_filetype_and_ext() check catches this and stops the attack. The problem is that not every upload path goes through that check. Patchstack says XML-RPC's wp.uploadFile method and the routine WordPress uses to extract cover art from uploaded MP3 files both write their bytes to disk with wp_upload_bits(), a function that never inspects content. The payload still lands on the server and still reaches the vulnerable code.

The fix is a commit numbered 7daaa50, which reworks the load() function so it inspects the file's content before constructing the Imagick object. Nothing that would be routed to a PostScript family decoder is passed along any more.

Concretely, the patched code sniffs the first chunk of every file and turns away several categories. PostScript and EPS are rejected whether they are spotted by their signatures (the %! marker, binary EPS headers or WordPerfect graphics), by extension, or by ImageMagick format specifier prefixes. Files that claim a PDF extension but do not begin with the real %PDF- marker are rejected as fake PDFs. Compressed files that ImageMagick would silently unpack, such as gzip and bzip2 archives, are refused as well, since they were another way to smuggle content past the checks.

There is a subtler detail. ImageMagick lets you force a particular handler by putting a prefix in front of a filename, for example EPS:innocent.png. The new code strips and inspects those prefixes, while taking care not to trip over Windows drive letters such as C:. The same trick can arrive through a remote URL or a stream, so the fix also parses filenames out of those sources before validating them.

Reaching the vulnerable code requires the ability to upload media, which means an Author level account or higher. Patchstack is explicit that this is not an anonymous, drive-by attack. But the bar is lower than it sounds on a multi-author publication, a membership site, a client site with contributors, or any site with open or loosely managed registration. On those sites, an author uploading a booby-trapped image is a realistic threat rather than a theoretical one. Where a site has only its owner and a small, tightly held group of editors, the exposure is smaller.

Update. Sites with automatic background updates enabled may already be covered, so a quick check of the version is worthwhile, and anyone who updates manually should prioritise this release, especially where accounts are handed out beyond a core team. For site owners who would rather not keep track of every core release themselves, AEU Hosting provides managed WordPress hosting, where the platform side of running a WordPress site is looked after for you.

Patchstack closes with a reminder about how media handling is approached in general: the risky part is usually not the image itself, but everything else the image library is quietly willing to open.