On this page (7 sections)
WordPress 7.0.4, a maintenance release, includes a security fix to how core passes uploaded media to ImageMagick. According to Patchstack's write-up, a logged-in Author could turn a file that looks like an image into code execution on the server.
If your site has more than one person who can upload media, such as multi-author blogs, membership sites, client sites with contributors or sites with loose registration, this update deserves attention soon. So far this story rests on a single publisher, Patchstack, which is the source for everything below.
What happened
WordPress uses ImageMagick, through the Imagick PHP extension, to resize and process images in the Media Library. ImageMagick can open far more than JPEG and PNG. It also reads PostScript, EPS and PDF, and to render those it calls Ghostscript, which Patchstack notes has a long history of being tricked into running commands. The researcher compares the class of problem to the older "ImageTragick" bugs.
The core issue was a mismatch. ImageMagick decides what a file is from its contents, while WordPress core's Imagick loader chose how to open a file from its extension alone. A file named like a PNG but containing PostScript could therefore be recognized by ImageMagick as PostScript and handed to Ghostscript.
Technical details
Per Patchstack, the WP_Image_Editor_Imagick::load() method checked only the file extension (special-casing PDF) and never inspected content. ImageMagick's read functions then sniff the leading bytes and ignore the name. Content beginning with certain PostScript, binary EPS or WordPerfect graphics signatures selects a coder that routes to Ghostscript.
The normal upload path is protected, because wp_check_filetype_and_ext() catches mismatched content. The gap is that not every upload path runs that check. Patchstack names two that write bytes with wp_upload_bits(), which does not inspect content:
- XML-RPC's
wp.uploadFilemethod - The cover-art extraction routine for uploaded MP3 files
In those cases the file still lands on disk and can reach the vulnerable loader. This article does not cover exploitation details, and none are needed to defend against it.
What the patch changes
According to Patchstack, commit 7daaa50 makes load() inspect the first chunk of each file before creating the Imagick object, so nothing is passed to a PostScript-family decoder. It rejects:
- PostScript and EPS files, identified by signatures, extension, or ImageMagick format-specifier prefixes
- Fake PDFs, meaning files with a PDF extension that do not start with the real %PDF- marker
- Compressed files such as gzip and bzip2 that ImageMagick would silently unpack
The fix also strips and inspects handler prefixes in filenames (for example a prefix that forces a particular coder), while avoiding false hits on Windows drive letters. Patchstack says the same handling applies to filenames arriving from remote URLs or streams. The research text is cut off at that point, so further details of the fix are not covered here.
Who is affected
Patchstack lists WordPress core 4.7 through 7.0 as affected. Reaching the code requires the ability to upload media, which means an Author account or higher, so this is not an anonymous drive-by issue.
Realistic exposure depends on who holds accounts:
- Higher risk: multi-author publications, membership sites, client sites with contributors, and sites with open or poorly managed registration
- Lower risk: sites where only you and a small group of trusted editors can log in
The research does not say whether the attack depends on Ghostscript being installed on the server. Because the described chain runs through it, checking whether your server has Imagick is a sensible way to understand your exposure, but it is not a substitute for updating.
How to check your exposure
This read-only WP-CLI command, run from your WordPress root, prints the installed core version. You want 7.0.4 or later, per the release Patchstack describes.
wp core versionThis lists users with the Author role so you can review who can upload media. Repeat with other roles that can upload, such as editor and administrator.
wp user list --role=author --fields=ID,user_login,user_email,user_registeredThis checks whether the Imagick PHP extension is loaded for the PHP command-line binary. Look for the line "imagick" in the output. Your web server may use a different PHP build, so also check phpinfo or your host's panel.
php -m | grep -i imagickWhat to do now
Updating core is the fix. Take a backup first, and if you manage many sites, stage the rollout.
This updates WordPress core from the WordPress root and then prints the version so you can confirm it is 7.0.4 or later.
wp core update
wp core version0 of 8 done
Detection and monitoring
Patchstack says it deployed a mitigation rule to affected sites connected to its service. If you are not covered by a virtual patch, updating is the dependable path.
After updating, watch for signs that someone already tried this. Look for unexpected files in the uploads directory, new Author accounts you did not create, and unusual calls to the XML-RPC endpoint in your access logs. A server-side malware scan helps, though outside-in detection has limits. If you suspect compromise, follow the website hacked guide.
For broader hygiene, the WordPress security checklist covers account roles and update practice, and Is my WordPress plugin vulnerable? explains how to check the rest of your stack. A web application firewall can add a layer, but it does not replace patching.
What we do not know
- No CVE identifier or CVSS score is given in the research
- Whether the flaw is being exploited in the wild is not stated
- Only one publisher, Patchstack, covers it so far, so details have not been independently confirmed
- The research text ends partway through the description of the fix
Treat these as open until the WordPress.org announcement or a CVE record confirms them.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.