On 6 August, WordPress released 7.0.3 with twelve security fixes and pushed them simultaneously to twenty-three active release branches, backported to every supported version from 4.7 forward. If auto updates are on, your core files are almost certainly patched already.
That is worth understanding properly, because the scale of the release tells you something and the thing it tells you is not "WordPress is insecure." It is that the security team treats a site running a nine year old branch as still worth protecting, and that most site owners have no idea which branch they are on.
What twenty-three branches actually means
Most software patches the current version and tells everyone else to upgrade. WordPress does not. A fix goes back through every branch still in use, which is why a site that has not had a major version bump since 2017 still receives security patches.
The engineering cost is significant. Each backport has to be adapted to code that has changed considerably across those years, then tested, then released. It happens because a large share of the web runs older WordPress, and abandoning those installs would leave millions of sites permanently exposed.
The practical consequence for you is that "we are on an old version so we are stuck" is not true. You are receiving security fixes. What you are not receiving is anything else, which matters more than most owners realise.
We maintain sites still running on branches that old, and the reason is almost never negligence. It is a plugin that was abandoned before the last major version, and updating core means replacing it first, which is a project nobody scheduled.
The twelve fixes, grouped by what they let an attacker do
The release covered pre-authentication cross site scripting, stored cross site scripting, privilege escalation, information disclosure, CSS injection, an email verification bypass, and server side request forgery. That list reads as a wall of jargon, so here is what the categories mean in practice.
Pre-authentication issues are the ones that matter most. They can be exploited by someone with no account and no credentials, which means the attacker pool is everyone on the internet rather than everyone with a login. One of the fixes in this release addressed a reflected cross site scripting flaw reachable on the login screen itself, scoring 8.9. A login page is, by necessity, exposed to anonymous visitors.
Privilege escalation means an account with limited rights can obtain more. On a site with a single administrator this is less alarming. On a membership site, a multi author publication, or anything with customer accounts, it is the difference between a subscriber and an administrator.
Server side request forgery lets an attacker make your server issue requests on their behalf. On shared hosting the impact is usually limited. On cloud infrastructure it can reach internal services that are not exposed publicly and that assume anything talking to them is trusted.
What backporting to nine year old code actually involves
A fix written against the current codebase rarely applies cleanly to a branch from 2017. Function signatures changed, sanitisation helpers were replaced, and the surrounding code was refactored more than once in between.
So each backport is a small piece of original engineering. Someone establishes whether the vulnerable pattern exists in that branch at all, adapts the fix to the code as it stood, and confirms it does not break behaviour that sites have depended on for years. Multiply by twenty three, coordinate so every branch releases simultaneously, and the reason simultaneity matters becomes clear: publishing one branch first would disclose the vulnerability to anyone reading the diff while the other twenty two remained exposed.
This is why security releases arrive as a single co-ordinated event with limited detail up front, and why the detail follows later. The gap between disclosure and patch availability is the window attackers work in, and the project closes it by not opening it.
Check that you actually received the update
Auto updates are enabled by default for minor releases, and most sites take them silently. Most is not all, and the failure modes are quiet.
Look in Dashboard, Updates and confirm the version. If it is below 7.0.3 on a 7.0 branch, or below the patched version of whichever branch you run, something is preventing updates. The usual causes are a disabled auto update constant in wp-config, file permissions that prevent writing to core directories, a security plugin blocking the update, or a hosting layer that manages updates on a schedule you do not control.
Managed hosts often apply these within hours and will say so on a status page. Unmanaged hosting is entirely your responsibility, and a site nobody has logged into for a year is unlikely to have applied anything.
Worth checking specifically: staging and development copies. Those are frequently forgotten, frequently public, and frequently share a database or a server with production.
If auto updates are switched off because one broke a site once, that is a solvable problem rather than a permanent position. We covered it in taking back control of auto updates.
The version number problem nobody mentions
Because fixes are backported, a site on an older branch receives security patches while remaining several major versions behind on everything else. That feels safe and is not the same as being current.
Older branches receive security fixes only. They do not receive the hardening improvements, API changes, or architectural work that reduces the chance of the next vulnerability existing at all. You are being protected from known problems rather than benefiting from work that prevents new ones.
There is also a compatibility trap. Plugin developers test against recent WordPress versions. A site three major versions behind will, at some point, hit a plugin update that assumes functionality it does not have, and that discovery usually happens during an emergency rather than during planned work.
If you are on an old branch, the fact that you received this patch is a good moment to plan the upgrade rather than a reason to defer it again. Our guidance on testing updates before they reach production covers how to do that without the usual risk.
What to do this week
Confirm the core version on every site you are responsible for, including staging copies and the client site you built four years ago and have not touched since.
Then audit plugins properly, because that is where the real exposure sits. For each one, establish when it was last updated by its developer, whether it is still in the plugin directory, and whether anything on the site actually uses it. Anything failing all three should be removed rather than deactivated, since deactivated plugin files remain on disk and remain reachable in some attack paths.
Finally, check that you would know if a site were compromised. Most owners find out from a customer, a browser warning, or a hosting suspension notice, which means the compromise has been running for weeks. File integrity monitoring and a real backup you have tested restoring are worth more than any single patch.
Frequently Asked Questions
Do I need to do anything if auto updates are on?
Verify rather than assume. Auto updates handle minor releases on most installs, but they fail silently when a constant is disabled in wp-config, permissions block writes, or a security plugin interferes. Checking the version in Dashboard, Updates takes ten seconds per site and is the only way to know.
What does a pre-authentication vulnerability mean?
It can be exploited without logging in. That changes the risk profile entirely, because the potential attacker is anyone who can reach your site rather than anyone who already has an account. Pre-auth issues are also easier to scan for at scale, so exploitation tends to follow disclosure quickly.
My site runs an old WordPress version. Am I unprotected?
For this release, no. Fixes were backported to twenty-three branches going back to 4.7, so an old branch still received the security patch. You are protected against these specific issues while missing every non security improvement since, which is a different and slower problem.
Is WordPress less secure than other platforms?
The vulnerability counts are large mostly because the ecosystem is enormous and the reporting is public and well organised. Core itself has a strong record. The meaningful difference is that WordPress security depends heavily on choices the site owner makes about plugins, and most platforms do not hand owners that much rope.
Should I remove plugins I am not using or just deactivate them?
Remove them. Deactivated plugins still have their files on the server, and some vulnerabilities are reachable in files that load regardless of activation state. Deactivation is a convenience, not a security control.
How quickly do these flaws get exploited after disclosure?
Faster than most maintenance schedules assume. Modern WordPress vulnerabilities are frequently exploited within hours of public disclosure, because disclosure gives attackers a precise target and scanning the web for it is cheap. A monthly patch window is not fast enough for anything pre-authenticated.
What if I am not sure whether a site was already compromised?
Patching does not remove an attacker who is already inside, which is the most common misunderstanding after a security release. If a site was vulnerable and exposed, check for unfamiliar administrator accounts, modified core files, unexpected scheduled tasks, and recently changed files in uploads directories. A clean patch on a compromised site simply closes the door behind someone already in the building.
Core is one part of the surface. The larger part is what you installed on top of it, which our WordPress development team audits as maintenance rather than after an incident.
Talk to our team if you would rather have someone audit the plugins properly than work through twenty sites by hand.