On 17 July 2026, WordPress.org shipped 7.0.2 and did something it very rarely does: it forced the update onto sites automatically. The reason was a vulnerability chain that let an attacker run code on a normal WordPress site without ever logging in.
WordPress 7.0.2 was released on 17 July 2026 as a security release. It fixed two separate issues:
Individually, either would have been serious. Chained together, they allowed an attacker to run their own code on a default WordPress install without logging in first. No stolen password, no compromised admin account, no tricking someone into clicking anything. Just a request to a site that happened to be running an affected version.
In security terms that's a pre-authentication remote code execution. It is close to the worst category of flaw a web application can have, and it is genuinely rare in WordPress core. Core has been audited heavily for two decades. The overwhelming majority of WordPress compromises come from plugins, themes, or weak credentials - not from core itself. That is exactly why this one attracted so much attention.
Versions prior to 6.8 were not affected. The fixes landed as follows:
If you are on the 6.8 branch, it's worth knowing that 6.8.6 did not close everything. Moving to a fully patched branch is the safer position.
WordPress.org enabled forced updates through the core auto-update system for sites running an affected version. Sites that support automatic background updates began updating themselves.
WordPress does not do this casually. The project is generally conservative about pushing changes onto sites without the owner asking. Choosing to override that says the security team judged the risk of leaving sites unpatched to be greater than the risk of updating them unannounced.
It's worth sitting with that for a second. The people who maintain WordPress decided it was safer to change your site without asking than to let it stay on the version it was on.
Once a security release ships, the fix is public. Anyone can read the code changes and work backwards to understand precisely what was wrong and how to exploit it. The window between a patch being published and attacks appearing in the wild is often measured in hours.
This inverts the intuition a lot of people have. A patch release is not the moment a vulnerability becomes dangerous to you - it's the moment it becomes dangerous toeveryone who hasn't applied it. The disclosure that protects patched sites is the same disclosure that arms attackers against unpatched ones.
Automated scanning makes this worse. Nobody is choosing to target a small business site in Brisbane. Attackers run broad scans looking for any site on a vulnerable version. Being small and uninteresting is not protection, because nothing about the process involves a human deciding you're worth attacking.
Core auto-updates handle minor and security releases well, and this incident showed the system working. Plugins are a different story, and they are where most real-world compromises start.
A typical WordPress site runs somewhere between ten and thirty plugins, each maintained by a different developer with a different attitude to security, a different release cadence, and a different likelihood of still being maintained at all. Some publish fixes within hours. Some take months. Some have been abandoned and will never publish another update, while still sitting installed and active on thousands of sites.
An abandoned plugin with a known vulnerability is one of the most reliable ways a site gets compromised, and it is invisible unless someone is actually checking.
We take the view that you should never have to find out about this kind of thing from a blog post - including this one.
The division is deliberate: we manage the platform, you manage your site. We're not going to silently update a plugin and risk breaking a page you spent a fortnight on. But you should never be in the dark about what needs attention, and you shouldn't have to go looking for it.
WordPress powers a huge share of the web, which makes it permanently worth an attacker's time to look for flaws in it. That's not a criticism of WordPress - the response here was fast, well-coordinated, and the forced-update mechanism worked. It's simply the reality of running popular software connected to the internet.
Staying current is not a maintenance chore you do when you get around to it. For the window between a patch and its application, it is the only thing standing between your site and a publicly documented exploit.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.