WordPress 7.0.1 to 7.0.4: What Each Update Fixed and Why You Cannot Wait

WordPress 7.0 arrived in May 2026, and the four releases that followed have been unusually security-heavy. Three of the four were security releases, one of them serious enough that WordPress enabled forced updates. If you would rather not track this yourself, our managed WordPress maintenance service applies security releases within days of publication.

This post breaks down what each release from 7.0.1 to 7.0.4 actually contained, how to check what you are running, and why the version you are on right now matters more than usual.

The Short Version

WordPress.org publishes a machine-readable list of which releases are considered secure. As of the 7.0.4 release, every version from 7.0 through 7.0.3 is flagged as insecure, and 7.0.4 is the only 7.0.x release marked current.

That is not a judgment call or an opinion about best practice. It is WordPress itself stating that the version you are on has known security issues. If your site is on anything below 7.0.4, that is the headline.

WordPress 7.0.1 — 9 July 2026

A maintenance release rather than a security one, fixing 31 bugs across Core and the Block Editor. The work concentrated on three areas: the block editor, the admin interface, and media handling.

Point-one releases after a major version are predictable. A major release exposes edge cases that no amount of beta testing surfaces, and the first maintenance release cleans them up. Nothing here was urgent, but it resolved a lot of small friction.

WordPress 7.0.2 — 17 July 2026

This is the one that mattered. A security release addressing one critical and one high severity issue, and severe enough that WordPress enabled forced updates through the automatic update system.

Why Forced Updates Are Significant

WordPress does not push forced updates casually. The auto-update system normally respects your configuration. Overriding that is reserved for situations where the risk of leaving sites unpatched outweighs the risk of updating them without asking.

If you have disabled automatic updates at the server or configuration level, that override may not have reached you. Sites that block auto-updates are exactly the sites most likely to still be sitting on 7.0.1.

WordPress 7.0.3 — 6 August 2026

Another security release, this time covering several security fixes, with immediate updating recommended. Coming three weeks after 7.0.2, it signalled that the 7.0 line was still being actively hardened.

WordPress 7.0.4 — 12 August 2026

The current release, and another security fix with an immediate-update recommendation. Arriving only six days after 7.0.3, it is a short gap that usually means something was found quickly after the previous release went out.

This is the version your site should be on today.

How to Check What You Are Running

There are three quick ways to find your version, in increasing order of reliability.

1. Log in to wp-admin and look at the bottom right of the dashboard, where the version is displayed
2. Go to Dashboard then Updates, which shows your version and whether an update is pending
3. If you have command line access, run wp core version for an unambiguous answer

If any of those report a number below 7.0.4, you are running a version WordPress.org classifies as insecure.

Why Sites Fall Behind on Security Releases

Nobody decides to run an insecure version. It happens through a handful of recurring situations, and they are worth checking against your own setup.

• Auto-updates disabled at server level: a hosting or configuration setting silently blocking core updates
• A failed update nobody noticed: the update errored, and without monitoring the site simply stayed on the old version
• File permissions: WordPress cannot write to its own directory, so updates fail quietly
• A staging or development copy: forgotten, unpatched, and often publicly reachable
• Fear of breakage: someone was burned by an update once and turned everything off
• No ownership: the site works, so nobody is responsible for checking it

Updating Safely When You Are Several Versions Behind

Security Releases Are Low Risk

It is worth separating two different things. Major version upgrades can introduce breaking changes and deserve staging and testing, which we covered in our guide to updating to WordPress 7.0. Security point releases are deliberately narrow, designed to be safe to apply quickly, and are the entire reason the auto-update system exists.

Treating a 7.0.1 to 7.0.4 update with the same caution as a 6.x to 7.0 upgrade is a mistake that leaves sites exposed for weeks.

A Sensible Sequence

1. Take a backup, because the cost is a few minutes and the alternative is unbounded
2. Apply the core update to 7.0.4 first, before touching plugins or themes
3. Load the front end and log in to wp-admin to confirm both still work
4. Check your key conversion paths: forms, checkout, and login
5. Only then move on to any pending plugin updates
6. Re-enable automatic updates for minor releases so this does not recur

Turn Automatic Updates Back On for Minor Releases

WordPress separates automatic updates for minor releases from major ones, and that distinction is useful. Minor and security releases can be applied automatically with very low risk. Major releases can be left for a human to schedule.

For most business sites, automatic minor updates plus a monitored, tested major upgrade process is the right balance. Turning everything off because one update once caused a problem trades a small, manageable risk for a large, invisible one.

If You Have Been Behind for a While

A site that has been running an insecure version for weeks should be updated and then checked, not just updated. Being exposed is not the same as being compromised, but it is worth confirming which one you are.

Look for administrator accounts nobody recognises, unexpected scheduled tasks, recently modified core files, and unfamiliar redirects. If any of that turns up, our hacked-site recovery service covers cleanup and hardening, and emergency support is there if the site is actively broken.

The Bottom Line

Three of the last four WordPress releases were security releases, and one triggered forced updates. Anything below 7.0.4 is officially flagged insecure. Updating a minor release is a low-risk, ten-minute job, and the gap between knowing that and actually doing it is where most compromised sites live.

Not sure what version you are on or whether your updates have been applying? Our free site audit checks your core version, update status, and known vulnerabilities, or see our care plans if you would rather it was simply handled.