WordPress 7.0.4 Security Release: What It Fixes and What to Check After Updating

WordPress 7.0.4 shipped on August 12, 2026. It is a security release, which means one thing: update now, read later.

If you have already updated, good. This post is about the part almost nobody does — verifying that the update actually worked, and that nothing broke quietly in the process.

 

What 7.0.4 actually fixes

One vulnerability, and it is a serious one:

Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript.

Broken down:

Remote code execution is the worst class of web vulnerability. Not “someone could see data they shouldn’t” — someone could run their own code on your server. From there: backdoors, spam injection, credential theft, using your server to attack others.

Authenticated Author+ means the attacker needs an account on your site with Author role or higher. That sounds reassuring until you count how many accounts your site actually has. A multi-author blog. A membership site with upgraded members. A WooCommerce shop with Shop Managers. An agency that never removed the freelancer from 2023.

Imagick and Ghostscript are server-side libraries WordPress uses for image and PDF processing. This is not an exotic configuration — it is the default on a large share of shared and managed hosting. If you don’t know whether your server uses them, assume it does.

The flaw is tracked as CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w. It was responsibly disclosed by the team at pwn.ai. The release was led by John Blackbourn, with significant input from Dennis Snell and Jeremy Felt.

Fixes are being backported as far as the 4.7 branch. That courtesy is worth reading carefully, though, because of what the release notes say next.

 

“Only the most recent version of WordPress is actively supported”

That sentence appears in every security release, and it is routinely misread.

Backports exist so that sites stuck on old major versions get emergency patches. They are not a support commitment. They cover the specific flaw being announced, nothing else — no other hardening, no performance work, no compatibility fixes for the PHP version your host will upgrade next quarter.

If your site is running 6.x because “the update might break the theme,” you are not maintaining a website. You are maintaining a countdown.

 

How to update

Two options:

1. Dashboard → Updates → Update Now. Works for most sites.

2. Download 7.0.4 from WordPress.org and deploy manually or via WP-CLI if you manage releases yourself.

Sites with automatic background updates enabled will have received it already — probably. Emphasis on probably; see point 1 of the checklist.

Before you click anything: take a full backup — files and database — and store it somewhere other than the server you are updating. A backup that lives on the compromised machine is not a backup.

If the site earns money, update a staging copy first. Yes, even for a security patch. A patched site that is down is not better than an unpatched site that is up.

 

The 7 things to check after updating

1. Confirm the update actually completed

Interrupted updates are more common than people think — a PHP timeout, a memory limit, a dropped connection mid-transfer. The symptom is nasty: the version number reports as updated while some files on disk are still the old ones.

Check Dashboard → Updates, and check the site’s readme.html or run wp core version if you have CLI access. If the site is stuck showing “Briefly unavailable for scheduled maintenance,” delete the .maintenance file in the WordPress root.

2. Verify automatic updates really ran

Hosts advertise automatic updates. They configure them differently, disable them for sites with certain plugins, and sometimes stage them over days. Do not take the marketing page’s word for it — open the dashboard and read the version number yourself.

3. Test everything that touches media and file uploads

This patch is about file upload and image processing. That is exactly where side effects show up. Test, in this order:

• Upload an image in the media library — check that thumbnails generate

• Upload a PDF — check that the preview renders

• Submit every contact form that accepts attachments, and confirm the mail arrives with the file attached

• On WooCommerce: test a downloadable product purchase end to end

• Anything with user-generated uploads: avatars, portfolios, support tickets

Silent failure is the pattern to watch for. The form still submits. The success message still appears. The attachment simply is not there.

4. Audit your user roles

The vulnerability required Author access or higher. So take the ten minutes:

Go to Users → All Users and sort by role. For every Administrator, Editor and Author, ask: does this person still work here, and do they still need this level of access? Downgrade or remove anything you cannot justify. Force a password reset on the accounts you keep, and require two-factor authentication for anyone at Administrator level.

Patching core closed the exploit. Your user table is what determined how exposed you were in the first place.

5. Check plugin and theme compatibility

Core security patches tighten how things are allowed to behave. Plugins that relied on the looser behaviour break.

Enable WP_DEBUG_LOG on staging, click through the site, and read the log — not just the visible pages. Check the checkout, the account area, the admin screens you rarely visit. Then update your plugins and theme too; developers ship compatibility fixes in the days following a core security release.

6. Look for signs of prior compromise

If your site sat unpatched on a vulnerable configuration for a while, patching does not undo an intrusion that already happened. Worth a look:

• Unexpected Administrator accounts

• Recently modified PHP files in wp-content/uploads — there should be none at all

• Scheduled tasks you do not recognise (wp cron event list)

• Unfamiliar entries in your server’s access logs around unusual hours

A malware scan is a reasonable next step. If anything looks wrong, treat it as an incident rather than a to-do item.

7. Write down what you did

Date, version, what you tested, what broke. It takes two minutes and it is the difference between diagnosing the next problem in an hour and diagnosing it in a week.

The uncomfortable part

WordPress 7.0.4 was announced on a Wednesday. Automated scanners begin probing for newly published vulnerabilities within hours of disclosure — the advisory tells attackers exactly what to look for, at the same moment it tells you.

That is the trade-off of responsible disclosure, and it is the right trade-off. But it means the window between “patch available” and “patch applied” is the entire risk. A site updated the same day was never really exposed. A site updated three weeks later was exposed for three weeks, to a published, documented, trivially scannable flaw.

Most sites fall into the second group. Not out of negligence — out of the ordinary reason things don’t get done: nobody was watching, and nobody’s job it was.

Or you can not think about it

This is what our WordPress Maintenance Package is for.

Core and plugin updates applied on a staging copy first, tested, then deployed to production. Offsite backups before every change. Security monitoring, so releases like 7.0.4 are handled in the window that matters rather than the week you happen to notice. A monthly report telling you what was updated and what was tested.

No dashboards to check. No release notes to read. No Wednesday-afternoon decisions about whether an update is safe.

See what’s included →

WordPress and WooCommerce. Nothing else.