WordPress 7.0.3: what's in the security release, and who needs to act
WordPress 7.0.3 landed on August 6, 2026. It's security-only, it fixes 12 vulnerabilities, and WordPress recommends updating immediately.
That advice is right. It's also where most coverage stops. Here's what's actually in the release, whether it applies to you if you're nowhere near WordPress 7.0, and what's worth doing about it.
What shipped
The release was led by John Blackbourn. No features, no bug fixes, security only. The whole thing is 31 files changed, 261 insertions and 86 deletions, and most of that is continuous integration config, dependency manifests and version bumps. The actual security work lands in about a dozen files of core.
Of the 12 vulnerabilities fixed, one has a CVE.
The one with a CVE: CVE-2026-64638
Rated High, CVSS 8.9. It's a pre-authentication reflected cross-site scripting issue on the login screen, and WordPress notes it has the potential to lead to PHP code execution through the plugin and theme editor.
Two things sit alongside that score:
It needs a person. The CVSS vector requires active user interaction. Someone has to get an administrator to follow a crafted link from a site the attacker controls. That makes it a social engineering attack with a technical payload attached, not something scanners find on their own.
The fix is a handful of escaping calls. The patch adds esc_html(), esc_url() and esc_attr() in wp-includes/user.php and wp-login.php. Output that should always have been escaped wasn't.
Affected versions are 4.7.0 through 7.0.2, which is every version of WordPress from 4.7 onwards.
The other 11
None of these carry a CVE, and five of them need an account on your site before they go anywhere.
Stored XSS, needs a Contributor account or higher. Four separate issues: in posts via the emoji settings element, in the Post Content block, in the Post Date block, and in Quick Edit on sites with a large number of users.
CSS injection, needs an Author account or higher. A bypass of the safe CSS attribute filter. The filter was failing open, returning "allowed" instead of "blocked" when it hit an internal limit.
Server-side request forgery in URL validation, allowing requests to link-local ranges. The blocklist now also covers 169.254.0.0/16, which is where cloud metadata endpoints live, plus CGNAT, multicast, TEST-NET and reserved ranges.
Three disclosure issues. Comments on password-protected posts were exposed through the Latest Comments block, notes leaked through comment feeds, and post slugs could be enumerated.
Privilege escalation on multisite networks with user registration enabled, letting a user create a new site. Single-site installs aren't affected.
A bypass of the email address confirmation flow.
Our read, and this is opinion rather than anything WordPress has said: most of this list is ordinary escaping and validation work in code paths that sat there for years and were finally audited properly. That's healthy to see in a release, not alarming.
WordPress credits every reporter by name 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 fixes to every branch still eligible for security updates, and all of them shipped on August 6 alongside 7.0.3. You do not need a major version upgrade to get patched.
| Your branch | Affected by | Update to |
|---|---|---|
| 7.0 | 12 of 12 | 7.0.3 |
| 6.9 | 11 of 12 | 6.9.6 |
| 6.8 | 8 of 12 | 6.8.7 |
| 6.7 | 8 of 12 | 6.7.6 |
| 6.6 | 8 of 12 | 6.6.6 |
| 6.5 | 8 of 12 | 6.5.9 |
| 6.4 | 8 of 12 | 6.4.9 |
| 6.3 | 8 of 12 | 6.3.9 |
| 6.2 | 8 of 12 | 6.2.10 |
| 6.1 | 8 of 12 | 6.1.11 |
| 6.0 | 8 of 12 | 6.0.13 |
| 5.9 | 8 of 12 | 5.9.14 |
| 5.8 | 8 of 12 | 5.8.14 |
| 5.7 | 7 of 12 | 5.7.16 |
| 5.6 | 7 of 12 | 5.6.18 |
| 5.5 | 7 of 12 | 5.5.19 |
| 5.4 | 7 of 12 | 5.4.20 |
| 5.3 | 7 of 12 | 5.3.22 |
| 5.2 | 7 of 12 | 5.2.25 |
| 5.1 | 7 of 12 | 5.1.23 |
| 5.0 | 7 of 12 | 5.0.26 |
| 4.9 | 7 of 12 | 4.9.30 |
| 4.8 | 7 of 12 | 4.8.29 |
| 4.7 | 7 of 12 | 4.7.34 |
| 4.6 and earlier | No longer receives security updates | Upgrade |
WordPress is clear that only the most recent version is actively supported. The backports are a courtesy, not a support commitment.
"8 of 12" does not mean four go unpatched
This is the bit that reads worse than it is. If you're on WordPress 6.8, you might reasonably assume 6.8.7 leaves four holes open.
It doesn't. The other four vulnerabilities don't exist in your branch, because the features they live in don't exist in your branch either. Editorial notes, the Post Content block's tag handling, and the script module and emoji handling all depend on code introduced in 6.9 and 7.0. You can't be vulnerable to a bug in code you're not running.
Patched for your branch is full coverage.
What to do
- Check your version. In WP Admin, go to Dashboard, then Updates. The version you're on is at the top.
- Take the update. Sites with automatic background updates have most likely started already.
- 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.
- Review who has an account. Five of the twelve issues explicitly need a Contributor or Author account first. If you hand out author access freely, or you allow open registration, that's the control worth tightening this week.
- If you're on multisite with open registration, treat the privilege escalation issue as the one to prioritise.
Common questions
Is WordPress 7.0.3 urgent?
Update promptly, but there's no need to panic. The highest-rated issue, the login screen XSS, needs an administrator to click a link from an attacker-controlled site. Five more need a Contributor or Author account on your site before they do anything, and the multisite issue needs a registered user on a network that allows open registration. Nothing here is a scanner pointing at a default install and taking it over.
Will WordPress update itself?
Sites that support automatic background updates will pick up a minor security release on their own, usually within hours. 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 don't have contributors. Do I still need to update?
Yes. The login screen issue (CVE-2026-64638) is pre-authentication, and the SSRF, disclosure and enumeration issues aren't described as needing an account either. "I don't have contributors" is also a statement about today, not about the next time someone gets added.
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, the 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 unglamorous point
The useful thing about a release like this isn't the CVE score. It's that a security-only release lands in every supported branch on the same day, so a site running WordPress 5.8 gets patched without touching a major version upgrade. That's a well-run project doing the boring work properly.
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.
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.
Sources
- WordPress 7.0.3 release announcement, wordpress.org, August 6, 2026
- Version 7.0.3 documentation, wordpress.org, August 6, 2026
- GHSA-52p2-r8wf-jcrf, the security advisory for CVE-2026-64638