The latest WordPress maintenance release 7.0.4 includes a quiet but important security fix, and it’s one worth understanding rather than just clicking “update” past. It changes how WordPress hands your uploaded media to ImageMagick, and it closes a path that could let a logged-in author turn an ordinary-looking image upload into code execution on your server.
Note that this affects WordPress core versions 4.7 all the way up to 7.0. The WordPress.org announcement can be found here.
What was actually wrong
You may already know WordPress leans on ImageMagick (through the Imagick extension) to resize and process the images in your Media Library. The problem is that ImageMagick understands far more than JPEGs and PNGs. It also opens PostScript, EPS, and PDF files, and to render those it calls out to Ghostscript, which has a long history of being talked into running commands it shouldn’t. This is the same family of problems as the old “ImageTragick” bugs.
Here’s the gap. ImageMagick decides what a file is by reading its contents, not its extension, while WordPress was mostly trusting the extension. So a file named holiday.png that actually contains PostScript would clear your upload checks, get handed to Imagick, which recognizes the PostScript inside and fires up Ghostscript. That mismatch is exactly where the risk lived.
The security vulnerability
The core WP_Image_Editor_Imagick::load() method decided how to pass an uploaded file to ImageMagick based only on the file’s extension, and never inspected the file’s contents:
try {
$this->image = new Imagick();
$file_extension = strtolower( pathinfo( $this->file, PATHINFO_EXTENSION ) );
if ( 'pdf' === $file_extension ) {
$pdf_loaded = $this->pdf_load_source();
// ...
} else {
if ( wp_is_stream( $this->file ) ) {
$this->image->readImageBlob( file_get_contents( $this->file ), $this->file );
} else {
$this->image->readImage( $this->file );
}
}readImage() or readImageBlob() sniffs the magic bytes and ignores the name. So, content starting with %!, \x04%!, \xC5\xD0\xD3\xC6, or \xFFWPC selects ImageMagick’s PS/EPS/WPG coder → Ghostscript, which executes the file as a PostScript program.
During a normal file upload flow, the wp_check_filetype_and_ext() function catches it and prevents the attack. But not every file upload path goes through that check. XML-RPC’s wp.uploadFile and the cover-art extraction routine for uploaded MP3s both write their bytes with wp_upload_bits(), which never inspects the content, so the payload still lands on disk and reaches the vulnerable code.
The patch
The commit 7daaa50 patches the vulnerability by updating the load() function which now checks the file’s content before constructing the Imagick object, so nothing is ever passed to a PostScript-family decoder.
Why this matters for your site
To reach the vulnerable code, someone needs to be able to upload media, which means an Author-level account or higher. So this isn’t an anonymous, drive-by attack. But think about who has an Author account on your site.
If you run a multi-author publication, a membership site, a client site with contributors, or anything with open or loosely managed registration, that bar is a lot lower than it sounds. On those sites, an Author uploading a booby-trapped “image” is a genuinely realistic threat, not a theoretical one. If it’s just you and a tightly held set of trusted editors, your exposure is smaller.
What the fix actually does
The patch teaches WordPress to inspect a file’s real contents before passing it to Imagick, and to reject anything that would be routed to a dangerous handler. Concretely, WP_Image_Editor_Imagick::load() now sniffs the first chunk of every file and turns away:
- PostScript and EPS, spotted by their signatures (
%!, binary EPS headers, WordPerfect graphics), by extension, or by ImageMagick “format specifier” prefixes. - Fake PDFs, meaning files claiming a PDF extension that don’t begin with the real
%PDF-marker. - Compressed files that ImageMagick would silently unpack (gzip, bzip2, and friends), which were another way to smuggle content past the checks.
There’s a subtler piece too. ImageMagick lets you force a particular handler by prefixing a filename, like EPS:innocent.png. The new code strips and inspects those prefixes, while being careful not to trip over Windows drive letters like C:, so an attacker can’t use the filename itself to steer Imagick toward Ghostscript. Because the same trick can arrive through a remote URL or a stream, the fix parses filenames out of those sources before validating them too.
What to do
Update. If you have automatic background updates enabled, you may already be covered, so it’s worth a quick check on your version. If you update manually, prioritize this one, especially on any site where accounts are handed out beyond your core team.
And it’s a useful reminder for how you think about media handling in general: the risky part usually isn’t the image. It’s everything else the image library is quietly willing to open.
