WordPress 7.0.3 Patches 12 Security Vulnerabilities

Security releases land on a fairly regular rhythm in the WordPress project, and most are unremarkable operationally. You let the auto-updater do its work and move on. This one deserves a closer look. The headline fix is a pre-authentication reflected cross-site scripting flaw on the login screen, reported by the team at pwn.ai, which the release note describes as having the potential to lead to PHP code execution.

The pre-authentication part is what changes the picture. It means an attacker needs no account, no password, and no existing foothold to reach the vulnerable code. A login screen is present and publicly reachable on the overwhelming majority of WordPress installations, so the exposed surface is not limited to membership sites or busy multi-author publications. It is, in practice, every site that has not yet updated. The release was led by John Blackbourn, and the project's guidance is unambiguous: update immediately.

How it works

WordPress 7.0.3 ships no new features. It is a security release in the strict sense: twelve fixes against the 7.0 branch, with no functional changes for editors, administrators or site visitors. That is deliberate. Keeping the change surface as small as possible keeps the risk of applying the update low, which removes the usual reason for holding it back pending a testing window.

Distribution happens three ways. Sites with automatic background updates enabled, the default for minor releases since WordPress 3.7, will pick up 7.0.3 on their own over the hours following release. Anyone who wants it sooner can trigger it from Dashboard, then Updates, then Update Now. Sites managed manually can download the release from WordPress.org and deploy it the usual way. The automatic background updates documentation covers the constants and filters that turn this behaviour on and off, which is worth a read if you have inherited a site and are not certain how the previous developer configured it.

The project is also backporting these fixes, where necessary, to every branch still eligible to receive security fixes, currently reaching back as far as 4.7. Those backports were still in progress when the release was announced and will ship as they become ready. Separately, WordPress 7.1 Release Candidate 2 has been published with all applicable fixes folded in, ahead of the 7.1 launch at WordCamp US between 16 and 19 August. The backport programme is a real safety net for older installations, but the project repeats the same caveat every time: only the most recent version of WordPress is actively supported.

What the twelve fixes cover

The login screen cross-site scripting issue is the one to act on first. It is tracked as CVE-2026-64638, with a matching GitHub advisory reference of GHSA-52p2-r8wf-jcrf, and it is the only issue in the set an unauthenticated attacker can reach. Everything else requires some level of existing access, which changes the risk calculation without making any of the fixes optional.

Four further stored cross-site scripting issues need a Contributor-level account or above: one via the emoji settings element, one in the Post Content block, one in the Post Date block, and one in Quick Edit on sites with a large number of users. A fifth authenticated issue allows CSS injection by an Author or above, through a bypass of the filter meant to keep style attributes safe. If your site accepts contributor registrations, runs a guest-post programme, or carries a long tail of dormant author accounts belonging to staff who left years ago, those are live concerns rather than theoretical ones.

The rest is a mix of disclosure and logic problems. A privilege escalation issue affected multisite networks with user registration enabled, where a user could create a new site. The Latest Comments block exposed comments left on password-protected posts. Post slugs could be enumerated, and notes in comment feeds could be disclosed. The email address confirmation flow could be bypassed. Finally, a server-side request forgery issue in URL validation permitted requests into link-local address ranges. That last one matters more than the phrasing suggests: link-local space is where most cloud providers expose their instance metadata service, so a request-forgery flaw that can reach it is taken seriously on any hosted infrastructure.

What this means for UK site owners and agencies

For a single site on decent managed hosting, the practical answer is short. Confirm the site is on 7.0.3, and if it is not, click update. Most UK hosts either allow core auto-updates through or apply minor releases themselves, so a large share of sites will be patched without anyone touching them. The work is in confirming that rather than assuming it.

For anyone running a portfolio of sites, the job is different in kind. The value is in knowing, quickly and without guessing, which installs are on which version. That is the whole argument for treating patching as a managed process with an inventory behind it, which is what our WordPress maintenance service exists to do. The sites that get compromised in the weeks after a release like this are rarely the ones someone forgot to update this morning. They are the ones nobody has looked at in two years, where auto-updates were disabled during a long-forgotten plugin conflict and never switched back on.

There is a UK-specific angle worth keeping in view. Two of the fixes are information disclosure issues, covering comments on password-protected posts and notes in comment feeds. Comment data routinely contains names and email addresses, which makes it personal data under UK GDPR. If you have concrete evidence that an unpatched site was exploited and personal data was exposed, that becomes a question of whether the incident is reportable to the Information Commissioner's Office within seventy-two hours. To be clear, patching promptly is not itself a reporting trigger, and a fixed vulnerability with no evidence of exploitation is not a breach. The point is that the reporting clock is short enough that you want your patching evidence in order before you need it, not after.

Practical considerations

Three things are worth watching. First, sites that have deliberately disabled core auto-updates will not receive this release on their own, and that group is larger than most people expect. Agencies often disable them on a client site to stabilise a fragile plugin stack, then leave the setting in place long after the original conflict was resolved. If that describes any site you look after, this release is the moment to check.

Second, being on an older branch is not the same as being safe. The backports through 4.7 will patch these specific issues on older installations, but they arrive later than the 7.0.3 release and they do nothing about the accumulated gap in everything else. An unsupported branch is a deferred problem, not a solved one.

Third, resist the temptation to jump to 7.1 to solve this. Release Candidate 2 carries the same fixes, but a release candidate is not production software, and 7.1 proper does not arrive until the WordCamp US window in the middle of August. The correct move today is the minor update to 7.0.3, followed by a normal, tested upgrade to 7.1 once it ships. This is the third patch on the 7.0 branch, after 7.0.2 in July, which is a reasonable cadence for a major branch rather than a warning sign about it.

FAQ