WordPress 7.0.4: one CVE, and two things have to be true

WordPress 7.0.4 landed on August 12, 2026, six days after 7.0.3. It fixes one vulnerability, it's rated High, and it's remote code execution.

That sounds worse than the last one, and in one specific way it is. But two things have to be true before it touches you at all, and a lot of sites fail both tests. Here's how to work out which group you're in.

What shipped

The release was led by John Blackbourn, with significant input from Dennis Snell and Jeremy Felt. Security only, no features, no bug fixes.

It's a genuinely small release by file count and a large one by line count. Seven files changed, 267 insertions and 43 deletions, and 235 of those insertions land in a single file: wp-includes/class-wp-image-editor-imagick.php. Everything else is version bumps, the About page, continuous integration config and dependency manifests. WordPress lists that one image file as the only revised file.

One vulnerability, one CVE.

The vulnerability: CVE-2026-65640

Rated High, CVSS 8.8. It's authenticated remote code execution via a malicious file upload, and it's classified as CWE-434, unrestricted upload of a file with a dangerous type.

The mechanism is worth understanding, because it explains who is exposed. When WordPress uses Imagick to process an uploaded image, Imagick hands PostScript and PDF files off to Ghostscript. The advisory is explicit that the weakness itself is in Ghostscript's handling of certain embedded files. WordPress core is not where the bug lives. WordPress core is what passes the file along.

So a user uploads something that Imagick decides is PostScript, Imagick calls Ghostscript, and Ghostscript does something it shouldn't.

Two conditions, both required

The advisory lists the prerequisites plainly, and both have to hold:

1. Imagick and Ghostscript are both in use on the server. Not every host runs this combination. Plenty of stacks use the GD library instead of Imagick, and plenty that do run Imagick don't have Ghostscript installed alongside it.
2. The attacker has an account with the upload_files capability, which in a default WordPress install means Author, Editor or Administrator. Contributors can't upload files, so Contributor access isn't enough here.

If either is false, this particular issue doesn't reach you. That's not a reason to skip the update, but it is a reason not to treat it as an emergency at 2am.

Is this more urgent than 7.0.3? For some sites, yes

The two releases are worth comparing properly, because the headline numbers are almost identical and the shape underneath is not.

The 7.0.3 headline issue, CVE-2026-64638, scored 8.9 and needed no account at all. What it did need was a person: an administrator had to follow a crafted link. That human in the loop is what kept it from being a scanner problem.

This one scores 8.8 and inverts that. It needs an account, but it needs no user interaction whatsoever. Nobody has to be tricked into clicking anything. An attacker who already has Author access on a vulnerable stack just uploads a file. And the outcome is code execution directly, rather than cross-site scripting with a possible route towards it.

Worth noting the two scores aren't a like-for-like comparison. 7.0.3's was scored under CVSS 4.0 and this one under CVSS 3.0, so 8.9 against 8.8 tells you very little. The vectors are the useful part.

The practical read: fewer sites are exposed to this than to 7.0.3, but the ones that are exposed are more exposed. If you run a multi-author site, a membership or community site, a publication with freelance writers, or client sites where staff hold Author accounts, this is the one to move on first. If you're the only person with a login, you are the only person who can exploit it.

What the patch actually does

The old code decided how to handle an upload by looking at its file extension. If the extension was pdf, it took the PDF path. Otherwise it handed the file to Imagick and let Imagick work it out. Trusting the extension is the whole problem.

The new code reads the actual bytes and makes up its own mind. In outline, it now:

• Reads the first 1,445 bytes of a file to sniff its type, rather than trusting what it's called.
• Rejects anything with a PDF extension that lacks the %PDF- signature.
• Rejects anything Imagick would parse as PostScript, identified three ways: by extension (.ps, .eps, .epsf and a dozen more), by magic bytes, and by Imagick format specifiers.
• Strips Imagick's FORMAT: prefixes off the filename, and loops while doing it, so a second specifier can't be promoted to the front once the first is removed.
• Rejects compressed files that Imagick would silently decompress before deciding what they are. This deliberately catches .svgz too, which the code comments acknowledge as a side effect.
• Routes to PDF handling based on the file's signature rather than its extension.

Our read, and this is opinion rather than anything WordPress has said: this is a bigger and more careful patch than the situation strictly demanded. It could have been a narrow block on PostScript. Instead the file-type decision was rebuilt to stop trusting filenames in general, which closes variations nobody has reported yet.

WordPress credits the reporting team in its release announcement.

"I'm not on WordPress 7.0. Am I patched?"

Yes, as long as you take the update. WordPress backported the fix to every branch still eligible for security updates, all the way to 4.7. You do not need a major version upgrade to get patched.

Unlike 7.0.3, where older branches were affected by fewer issues than current ones, there's no partial coverage here. There's one vulnerability and every branch back to 4.7 has it.

WordPress is clear that only the most recent version is actively supported. The backports are a courtesy, not a support commitment.

How to tell whether your server runs Imagick and Ghostscript

You don't need shell access. In WP Admin, go to Tools, then Site Health, then the Info tab, and open the Media Handling section. WordPress reports the ImageMagick version and the Ghostscript version there directly.

If Ghostscript shows as unavailable, this specific vulnerability doesn't apply to your site. Take the update anyway, because that's a fact about your server today, and servers get rebuilt, migrated and reconfigured without anyone rechecking a CVE from last August.

What to do

1. Check your version. In WP Admin, go to Dashboard, then Updates. The version you're on is at the top.
2. Take the update. Sites with automatic background updates have most likely started already.
3. Check Site Health for Ghostscript if you want to know how exposed you actually were.
4. Review who holds Author access or higher. This is the control that matters for this issue. Contributor accounts can't upload files, so the line here is Author, not Contributor.
5. Include staging and development copies. A forgotten but publicly reachable staging site carries the same exposure as the live one, and it's the copy nobody is watching.

Common questions

Is WordPress 7.0.4 urgent?

It depends on your site in a way that 7.0.3 didn't. If your server runs Imagick with Ghostscript and people you don't fully trust hold Author accounts, treat it as urgent and update today. If either of those isn't true, update promptly on your normal schedule. There's no evidence of exploitation in the wild that WordPress has published, and no proof of concept in the advisory.

Will WordPress update itself?

Sites that support automatic background updates will pick up a minor security release on their own, usually within hours. WordPress says so directly in the announcement. That's the design: minor releases land in-branch precisely so they can be applied without anyone reading a CVE first. Worth confirming rather than assuming, especially on sites where a plugin or a constant has disabled auto-updates.

I'm the only user on my site. Do I still need to update?

You're not realistically exploitable through this path, since the attacker needs an account that can upload files and you're the only one who has one. Update anyway. "I'm the only user" is a statement about today, and the update costs you nothing.

Do I need to update Ghostscript as well?

The advisory places the underlying weakness in Ghostscript, so keeping the server's packages current is sound practice regardless. On managed hosting that's your host's job rather than yours. What the WordPress patch does is stop WordPress handing those files to Ghostscript in the first place, which protects you whatever version the server happens to be running.

What if I'm on WordPress 4.6 or older?

There's no patch coming. WordPress stopped issuing security updates for 4.6 and earlier, so the fix is to get onto a supported branch. If that's where you are, this release is the least of it.

Does this affect plugins or themes?

No. This is a WordPress core release. Plugin and theme vulnerabilities are tracked and patched separately, which is why keeping core current is necessary but never sufficient. The Stripe for WooCommerce 10.8.5 release from earlier this month is a good example of the separate track.

The unglamorous point

Two security releases in six days is not a sign of a project in trouble. It's a sign of one that ships a fix when a fix is ready instead of holding it for a tidier release window, and then backports it across 24 branches on the same day. A site running WordPress 5.8 got patched without touching a major version upgrade. That's the system working.

What quietly fails is the other half: whether the update actually reaches your sites. Auto-updates disabled during a debugging session two years ago, a staging copy nobody remembers, a site where an update once broke something so updates got switched off and never back on. We've written before about how little time there is between disclosure and exploitation, and the gap that matters is almost never the one between the patch shipping and you reading about it.

On Wordify, this is the kind of release the update lifecycle is meant to absorb for you. Safe Updates apply plugin, theme and core updates automatically, run a health check afterwards, and roll the site back on their own if something breaks. A minor security release should be something you read about later, not something you action.

If you're not sure whether your sites are on a patched version, talk to us and we'll check with you.

More on this

• WordPress 7.1: what's coming for site owners (and what isn't), the feature release landing August 19, 2026, and how to treat it differently from a security minor like this one.
• WordPress 7.0.3: what's in the security release, and who needs to act, the previous release in this series, six days earlier and twelve issues larger.
• WordPress 7.0 "Armstrong" walkthrough, what the major release this branch belongs to actually introduced.
• WordPress security in the age of negative-day exploits, why patch latency matters more than patch count.
• Managing updates across a fleet of client sites, if the "who has Author access" question just got complicated for you.

Sources

• WordPress 7.0.4 release announcement, wordpress.org, August 12, 2026
• Version 7.0.4 documentation, wordpress.org, August 12, 2026
• GHSA-8vr3-7mxf-gx8w, the security advisory for CVE-2026-65640
• The 7.0.3 to 7.0.4 diff, WordPress/wordpress-develop on GitHub