WordPress 7.0.4 Security Update: The Complete Guide

The WordPress 7.0.4 security update patches a critical remote code execution vulnerability affecting sites that process images with Imagick and Ghostscript. Released on August 12, 2026, it is a mandatory update: if your host has ImageMagick and Ghostscript installed, an attacker with Author-level access could run malicious code on your server through a crafted file upload. This guide explains exactly what broke, who is at risk, and how to patch it in minutes.

What Is the WordPress 7.0.4 Security Update?

WordPress 7.0.4 is a targeted security release, not a feature update. It contains a single fix for a vulnerability tracked as CVE-2026-65640, which carries a CVSS score of 8.8 out of 10 – high severity. The WordPress security team pushed the release the same week the flaw was privately reported, and it was also backported to older branches so sites that haven’t upgraded to WordPress 7.x in years are still covered.

Because WordPress powers roughly 41% of all websites according to W3Techs’ 2026 market share data, a flaw like this gets patched fast and disclosed carefully. The official release notes are available directly from WordPress.org’s news blog, and security researchers at SecurityWeek broke down the technical details for site owners the same week.

That scale is exactly why security researchers hunt for WordPress bugs in the first place. A single flaw that reaches even a fraction of installs still touches millions of live sites, which is why the core security team treats every RCE report as urgent regardless of how narrow the exploitation conditions are.

What Does the WordPress 7.0.4 Security Update Fix?

The WordPress 7.0.4 security update fixes an authenticated remote code execution (RCE) flaw in how WordPress hands uploaded image files to the Imagick PHP extension. The bug lives in Ghostscript, the tool Imagick calls behind the scenes to process certain file types, and it is nearly a decade old – only recently discovered in this context.

• The trigger: a specially crafted file, disguised with a misleading filename, tricks Imagick into invoking Ghostscript’s PostScript interpreter.
• The payload: PostScript is a full programming language, so a malicious file can execute arbitrary code on the server once interpreted.
• The requirement: the attacker needs Author-level file upload permissions on the target site – this is not an unauthenticated, drive-by exploit.
• The fix: WordPress core now inspects file contents before handing them to Imagick, and blocks filename tricks that force Ghostscript into PostScript mode.

In plain terms: WordPress closed the door between “someone can upload a file” and “that file can run commands on your server.” That gap is exactly what turns a minor permissions issue into a full server compromise.

What Is Ghostscript and Why Does WordPress Use It?

Ghostscript is an open-source interpreter for PostScript and PDF files that has shipped with Linux server distributions for decades. WordPress itself never calls Ghostscript directly – it calls the Imagick PHP extension to resize, crop, and generate thumbnail versions of uploaded images, and Imagick quietly hands certain file types off to Ghostscript to do the actual decoding.

That handoff is the weak link. Ghostscript was built to interpret PostScript as a general-purpose language, so when Imagick can be tricked into treating an image upload as a PostScript file, whatever code is embedded in that file runs with the permissions of the web server process. This class of bug – an image library silently invoking a much older, more powerful interpreter – has surfaced in other CMS platforms too, which is why the fix here works by validating file content before Imagick ever touches it, not by patching Ghostscript itself.

Why Does This Vulnerability Matter So Much?

Remote code execution is the most severe category of web vulnerability because it skips every layer of protection below it. A cross-site scripting bug lets an attacker run script in a visitor’s browser. An SQL injection bug lets an attacker read or alter database rows. RCE lets an attacker run arbitrary commands on the server itself – installing backdoors, reading other sites on the same server, pivoting into connected systems, or wiping the site entirely.

The CVSS score of 8.8 reflects that severity even with the Author-level access requirement attached. Multi-author sites – membership platforms, news outlets, agencies with client logins, online course sites – routinely hand Author or Editor roles to dozens of people, and any one of those accounts being compromised through a weak password or phishing email becomes the entry point for this exploit chain.

Is Your Site at Risk?

Not every WordPress site is exposed the same way. Risk depends on your hosting stack and who has upload access on your site. Use the table below to check where you stand.

If you don’t know which image library your host uses, check Tools → Site Health → Info → Media Handling in your WordPress dashboard. It lists whether Imagick or GD is active, along with the exact version numbers of both PHP and any imaging extensions installed. When in doubt, update anyway – the patch has no downside for sites that were never at risk, and it closes the door for good if your hosting configuration ever changes.

How Do You Install the WordPress 7.0.4 Security Update?

Most sites don’t need to do anything. WordPress ships security releases as background updates by default, so the vast majority of installs already auto-updated within hours of the August 12 release. To confirm and, if needed, update manually, follow these steps.

1. Log in to wp-admin and go to Dashboard → Updates.
2. Check the version number at the bottom of any admin page, or under Dashboard → At a Glance.
3. If it reads anything below 7.0.4 (or below the matching backported version for your branch), click Update Now.
4. Take a full backup first if you’ve disabled auto-updates or run a heavily customized stack – standard practice before any core update.
5. After updating, revisit Site Health to confirm no warnings appear and the version number matches.

If you manage multiple sites, WP-CLI makes this a one-line job: wp core update followed by wp core version to confirm. Agencies running dozens of client sites should script this across every install this week, not just the ones they remember.

For hosts with auto-updates disabled at the server level – common on some managed WordPress platforms that stage releases – check your host’s status page or support channel directly. Most major managed hosts had 7.0.4 rolled out to every customer within 24 to 48 hours of release, but a small number stage security patches through a review queue, which can add a few days of delay on shared infrastructure.

Run these three commands in order: wp core update, then wp core version to confirm, then wp core verify-checksums to validate the install.

The third command, wp core verify-checksums, is worth running after any security update. It compares your installed core files against the official WordPress.org checksums and flags anything that’s been modified – useful for confirming a clean update and for catching any leftover backdoor files if your site was already compromised before you patched.

What Should You Do If You Can’t Update Immediately?

Some sites run on frozen environments – managed hosting with delayed rollouts, or custom builds that need testing before any core change. If you can’t patch today, reduce your exposure with these mitigations until you can.

• Restrict upload capability. Use a role-management plugin to temporarily strip the upload_files capability from the Author role, so only Editors and Administrators you fully trust can add media until the patch is live.
• Ask your host about Ghostscript. Contact support and confirm whether Ghostscript is installed on your server. If nothing else on the box depends on it, request that they disable or remove it at the system level as a belt-and-suspenders measure.
• Add a WAF rule for mismatched uploads. Most web application firewalls, including the free tiers of popular WordPress security plugins, can block uploads where the file extension doesn’t match the detected MIME type – exactly the trick this exploit relies on.
• Audit your user list. Go to Users in wp-admin and review every account with Author access or above. Remove anything you don’t recognize, and force a password reset on any account that hasn’t logged in recently.

None of these replace the patch. They only buy time. Treat them as a stopgap measured in days, not a long-term substitute for running 7.0.4 – and remove the upload restriction once you’ve confirmed the update is installed, so your editorial team isn’t stuck.

How Does This Compare to WordPress’s Other 2026 Releases?

WordPress 7.0.4 arrives in the middle of a busy release cycle. Here’s how it fits alongside the maintenance release before it and the feature release right behind it.

WordPress 7.1 lands the same week as this security patch, timed to close out WordCamp US 2026 in Phoenix. If you’re planning that upgrade, install 7.0.4 first – it’s the smaller, safer change, and you want your baseline secure before adding new features on top.

Does This Update Affect Site Performance or SEO?

No. WordPress 7.0.4 only changes how Imagick validates files before processing – it doesn’t touch page speed, markup, or rankings directly. But a compromised site absolutely does. Google routinely deindexes or flags hacked sites, and recovery can take weeks even after cleanup. Treat this patch as part of the same maintenance discipline covered in our guides on speeding up WordPress and fixing common WordPress SEO issues – a fast site that gets hacked loses every ranking gain overnight.

If your site also outputs structured data, it’s worth double-checking your schema markup still validates after any core update. Our walkthrough on adding JSON-LD schema in WordPress covers how to verify that quickly.

What Happens If a Site Gets Compromised Through This Flaw?

Unpatched RCE vulnerabilities rarely stay theoretical for long once technical details are public, which is exactly the situation after SecurityWeek and other outlets published the mechanics of CVE-2026-65640. Automated scanners built by both researchers and attackers start probing for vulnerable installs within days of disclosure, looking for sites still running Imagick without the fix.

A successful exploit typically follows a predictable pattern: the attacker uploads the malicious file through a compromised or malicious Author account, the payload executes and drops a persistent backdoor (often a small PHP file hidden in the uploads directory or theme folder), and that backdoor survives even after the original vulnerability is patched. This is why running wp core verify-checksums after updating matters – patching the hole doesn’t remove anything an attacker already planted through it.

Recovery from a full RCE compromise usually means a complete file and database audit, rotating every credential and API key connected to the site, and in many cases restoring from a backup taken before the exploit window. That process costs far more time than the two minutes it takes to confirm your version number today.

Quick Checklist: WordPress 7.0.4 Security Update

Work through this list in order. It takes most site owners under ten minutes for a single site.

1. Check your current WordPress version in Dashboard → At a Glance.
2. If it’s below 7.0.4 (or the matching patched version for your branch), update immediately.
3. Confirm whether your host uses Imagick via Site Health → Info → Media Handling.
4. Review every Author, Editor, and Administrator account for anything unfamiliar.
5. Run wp core verify-checksums if you have WP-CLI access, to rule out an existing compromise.
6. If you manage client sites, repeat this checklist for every install this week, not just the ones you remember.

Frequently Asked Questions

Do I need to manually install the WordPress 7.0.4 security update?

Usually not. WordPress applies security releases as automatic background updates unless a site owner has explicitly disabled them in wp-config.php or through a management plugin. Check Dashboard → Updates to confirm your version reads 7.0.4 or higher, and if it doesn’t after 48 hours, update manually rather than waiting.

Is my site vulnerable if I don’t use Imagick?

No. The flaw only triggers when a site’s image processing library is Imagick calling Ghostscript. Sites using the GD library, which many shared hosts default to, are not affected by this specific vulnerability.

What is CVE-2026-65640?

CVE-2026-65640 is the official vulnerability identifier for the authenticated remote code execution flaw patched in WordPress 7.0.4. It has a CVSS severity score of 8.8, classified as high.

Can a subscriber-level account exploit this vulnerability?

No. Exploitation requires file upload rights, which start at the Author role by default. Subscriber and Contributor accounts cannot upload files and cannot trigger this flaw on a standard WordPress install.

Will WordPress 7.0.4 break my plugins or theme?

It’s extremely unlikely. This is a narrow security patch touching file-upload validation, not a feature release, so it doesn’t change any public APIs, hooks, or template functions that plugins and themes rely on. It carries far less compatibility risk than a major version like the upcoming WordPress 7.1, which is worth testing on staging first.

Does this affect WordPress Multisite networks?

Yes, and often more severely. A Multisite network with open registration effectively hands file-upload rights to a much larger, less vetted pool of accounts than a single site typically would. Network administrators should treat updating as the top priority and audit sub-site user roles immediately after patching.

How do I know which WordPress version my site is running?

Log in to wp-admin and check the bottom-right corner of almost any screen, or go to Dashboard → At a Glance. Both display your current core version instantly, and Site Health → Info shows it alongside your PHP, database, and server configuration in one place.

The Bottom Line

The WordPress 7.0.4 security update closes a high-severity remote code execution hole that only needed an Author account and the right server configuration to become a full compromise. Most sites already have it thanks to automatic background updates, but it’s worth the thirty seconds to confirm your version number today, especially with WordPress 7.1 arriving right behind it.

Security releases like this one are also a good reminder to build a lightweight maintenance habit: check your version monthly, review user roles quarterly, and keep backups current enough that “restore and move on” is always an option. That habit costs a few minutes a month and is far cheaper than recovering from a breach.