Twelve vulnerabilities exposed across WordPress 4.7 to 7.0.2

WordPress released 7.0.3 on 6 August 2026, fixing twelve separate vulnerabilities. The most serious, CVE-2026-64638, is a pre-authentication flaw on the login screen rated 8.9 out of 10, and it affects every version of WordPress released since 2016. Update to 7.0.3, 6.9.6 or 6.8.7. This arrives three weeks after the WP2Shell chain, and that pattern matters more than any single item on the list.

What's happening

WordPress shipped 7.0.3 on 6 August 2026. It is a security release, not a feature release, and it fixes twelve separate vulnerabilities reported by eleven different research teams. The WordPress security team is recommending that sites update immediately.

The headline issue is CVE-2026-64638, tracked as advisory GHSA-52p2-r8wf-jcrf and reported by the team at pwn.ai. It is a pre-authentication reflected cross-site scripting flaw on the login screen, rated 8.9 out of 10, with a documented potential to escalate to PHP code execution. It affects WordPress 4.7.0 through 7.0.2, which is to say essentially every WordPress site built in the last nine years.

One honest qualification, because it changes how urgently you should treat this. Unlike WP2Shell three weeks ago, this is not a point-and-shoot remote takeover. The advisory is explicit that escalation to code execution depends on conditions outside the attacker's control, and that it requires social engineering plus active participation from the victim. An attacker has to get one of your administrators onto a malicious page and get them to interact with it. That lowers the practical risk considerably. It does not lower it to zero, because the people most likely to click a convincing link about their own website are the same people who administer it.

As at the time of writing there is no public evidence of this being exploited in the wild, and no proof-of-concept exploit has been published. That is a meaningful difference from WP2Shell, which was in CISA's Known Exploited Vulnerabilities catalog within four days. Treat this as urgent maintenance rather than an emergency, and get it done this week.

You can read the official WordPress release announcement for the vendor's own account of the fix.

How fast this is moving

The severity of any single item on this list matters less than the interval between releases. This is the second emergency security release for WordPress core in under three weeks.

The twelve issues

• Pre-authentication reflected XSS on the login screen, with potential to lead to PHP code execution. Reported by pwn.ai.
• Privilege escalation on multisite networks. Reported by Aikido Security.
• Contributor and above stored XSS in the emoji settings. Reported by Asaf Mozes of amosec.
• Contributor and above stored XSS in the Post Content block. Reported by n05ec.
• Contributor and above stored XSS in Quick Edit. Reported by Naveen S and Ajmal Moochingal.
• Contributor and above stored XSS in the Post Date block. Reported by Alex Concha of the WordPress Security Team.
• Information disclosure in the Latest Comments block, exposing comments left on password-protected posts. Reported by Ehtisham Siddiqui.
• Post slug enumeration. Reported by HDWSec.
• Comment feed notes disclosure. Reported by Elio Gubser.
• Author and above CSS injection. Reported by Anthropic.
• Email confirmation bypass. Reported by 0ways.
• Server-side request forgery in URL validation. Reported by Andrew Mohawk and others.

Five of those twelve require an authenticated account at contributor level or higher. Whether that matters to you depends entirely on how your site is set up. If you run a single-author brochure site with one administrator and no public registration, those five are close to irrelevant for you. If you accept guest posts, allow open registration, run WooCommerce with customer accounts, or have staff logins with editorial roles, they are not, because they turn a low-trust account into a way to plant script that runs against your administrators.

The multisite privilege escalation deserves separate attention. If you run a multisite network, treat that one as your priority rather than the login screen flaw, because it needs no social engineering to be useful to an attacker who already has a foothold on one site in the network.

Affected and fixed versions

• Update the 7.0 branch to 7.0.3, the 6.9 branch to 6.9.6, and the 6.8 branch to 6.8.7.
• Fixes have been backported to every branch still eligible for security support, all the way down to 4.7.34. The full list runs 4.7.34, 4.8.29, 4.9.30, 5.0.26, 5.1.23, 5.2.25, 5.3.22, 5.4.20, 5.5.19, 5.6.18, 5.7.16, 5.8.14, 5.9.14, 6.0.13, 6.1.11, 6.2.10, 6.3.9, 6.4.9, 6.5.9, 6.6.6, 6.7.6, 6.8.7, 6.9.6 and 7.0.3.
• If you are on a version older than 4.7, there is no patch for you. Upgrading is the only option.

That backport list is worth sitting with for a moment. Twenty-four separate patched releases, reaching back to a version first published in December 2016, means there is no WordPress install anywhere that was not affected by this. Not one that was well maintained, not one that was minimal, not one that avoided plugins.

Sites that support automatic background updates began receiving the update shortly after release. As with the last notice, do not treat that as a guarantee. Automatic updates do not reach sites with auto-updates disabled, sites where file permissions stop core writing to itself, sites whose host manages updates on its own schedule, or sites with modified core files. Check the version yourself.

What to do if you run a WordPress site

• Check your version. It is shown in the dashboard under Updates, and in the "At a Glance" panel. If you are below 7.0.3, 6.9.6 or 6.8.7, update this week.
• Verify the update actually applied. Load the dashboard again afterwards and confirm the number changed. An update that silently failed on a permissions error looks identical to one that worked, right up until it doesn't.
• Review who has an account. Five of these twelve need a logged-in contributor or above. Remove accounts that are no longer used, and drop anyone sitting at a higher role than their job requires.
• If you run multisite, prioritise this, and audit for unexpected role or capability changes across the network afterwards.
• Warn whoever administers the site. The headline flaw needs an administrator to follow a link and interact with the page it lands on. A message about your own website, arriving while a security story is in the news, is exactly the pretext that gets clicked. Anything asking you to log in should be reached by typing the address yourself, never by following a link.
• Do not skip this because nothing is being exploited yet. Patch details are public, and the gap between a public advisory and a working exploit is usually measured in days.

How we help our clients

Three weeks ago we wrote about WP2Shell, a pre-authentication remote code execution chain in WordPress core. Today it is twelve more issues in the same codebase, including one that reaches back through every version released since 2016. Neither of these was a plugin. Neither was a theme. Neither was anything a site owner did wrong. Both were in the platform itself.

That is the pattern we keep pointing at, and it is the honest reason we no longer recommend WordPress as the default for a small business website. The usual advice, keep your plugins lean and your themes trustworthy, is genuinely good advice, and it would not have prevented a single item on this list. If your site is a set of pages that describe your business and a form that lets people contact you, then a public login screen, a REST API, a database and an admin panel are all attack surface you are carrying for no return.

Our alternative, Jigsaw, has none of them. The site we hand you is plain HTML and CSS. There is no login to attack, no database to inject into, and no code executing on the server when a visitor loads a page. A security release like this one is simply not something you need to read.

For clients whose site genuinely needs a CMS, our WordPress management plan runs on tooling rather than on someone remembering to click update: versions tracked against published vulnerability data so security releases are applied on our schedule, multi-factor authentication on administrator logins, brute force protection, alerting on new or newly escalated admin accounts, a web application firewall, malware and file integrity scanning, and hourly off-server backups. Role auditing is part of that too, which is what takes the sting out of the five contributor-level issues in this release.

If you are not sure which version your site is running, or you would like us to check and update it for you, request a chat.

Corey Crowden Creative and Technical Lead (And director of Tas Web Co)