WordPress 7.0.4 patched a code execution hole: whose servers were actually at risk

What the patch actually covers

The security team listed a single item: authenticated remote code execution by a user at Author level or above, through a malicious file upload, on sites that use Imagick and Ghostscript. The report came from the team at pwn.ai. The version page lists the changed files, and the list is one line long:

/wp-includes/class-wp-image-editor-imagick.php

No packages were revised either, so this is a single purpose security release rather than a maintenance drop carrying forty bug fixes. Applying it immediately therefore carries almost no regression risk, which for anyone running a shop is usually the deciding factor.

The fix also went out on every affected branch down to 4.7.35, twenty three of them. A site still sitting on WordPress 5.2 has a patched build waiting; anything at 4.6 or older no longer receives security updates at all. That decision says something on its own, because WordPress does not backport an ordinary bug eight years deep.

Three commands that tell you where you stood

Run them in this order. Version first, then Imagick, then Ghostscript. If either of the last two is missing, this vulnerability was never in scope for you.

wp core version
php -r 'echo extension_loaded("imagick") ? Imagick::getVersion()["versionString"] : "no imagick";'
gs --version

Our server answered like this on 15 August 2026:

7.0.4
ImageMagick 6.9.12-98 Q16 x86_64 18038
10.02.1

All three conditions met. The only thing that covered us before the announcement reached us was core automatic updates, which is the WordPress default and which we had not switched off.

The policy.xml trap, and it cost us twenty minutes

Every ImageMagick hardening guide tells you to lock down policy.xml so the PostScript and PDF coders cannot run. The advice is sound. The problem sits somewhere else: on a stock ImageMagick 6 install under Debian or Ubuntu, those lines live inside the file's documentation comment, not inside the active configuration. We grepped, found the line, relaxed for a moment, then tested whether it did anything. It did not.

Two commands separate belief from fact. The first prints the policies actually in force; the second proves Ghostscript still gets invoked:

identify -list policy
convert sample.pdf out.png

If the first output contains no rows labelled Coder, you have no coder restriction regardless of what the file appears to say. If the second returns a Ghostscript error rather than a permission error, the path is open. On our server it returned a Ghostscript error. So go and count how many people hold Author access to your dashboard, because WordPress lets an Author upload pdf, psd, xps and oxps by default, and those are precisely the formats that route through Ghostscript.

A security plugin would not have caught this

Writing that sentence is expensive for anyone selling security plugins, and it is still true. Wordfence and its peers work at the request layer: suspicious payloads, bad addresses, failed logins. Here the upload was entirely legitimate, performed by someone who genuinely held upload rights, and the processing happened inside a core file. No application firewall rule treats that as anomalous.

Three things did matter, and all three are free: core automatic updates left on, the smallest possible number of Author accounts, and an ImageMagick install that is genuinely restricted rather than apparently restricted.

Now the honest size of the risk

If you are the only user on your site, your practical exposure here was close to zero. An authenticated Author level vulnerability means the attacker needs an account first. The real risk lives elsewhere: sites with open registration, multi author publications, company blogs where ten people hold publishing rights and nobody has reviewed the user list in two years. If that describes you, the patch is half the job and reviewing that list is the other half.

We walk through the same logic in the signals a site gives off before it gets breached, and if you would rather have someone outside your own team look at permissions and server configuration, a security review of your server and access levels starts from exactly this checklist.

One closing point that has nothing to do with the news and everything to do with you: a site sitting on shared hosting with untouched configuration does not get to make these decisions. We covered what that costs in how hosting configuration shows up in site performance, and if you are building from scratch, a site built with its server configuration decided on day one is cheaper than retrofitting all of this after launch.

Sources

• The WordPress 7.0.4 release announcement for the date, the vulnerability description and the reporter
• The 7.0.4 version page for the changed file list and the backported branches

Both sources, and every command above, were run and checked on our own server on 15 August 2026.