On July 17, WordPress released version 7.0.2. It was a security release, and the team enabled forced updates via the auto-update system to push it out to sites that hadn’t taken it yet. They don’t do that often.
The reason they did it this time is worth understanding, because it goes against the usual story people tell about WordPress security.
WordPress has a security reputation, and it’s mostly about plugins
When people say WordPress is insecure, they’re usually thinking of plugins. WordPress runs a large share of the web, and much of that runs on third-party plugins of wildly varying quality. Most WordPress security problems trace back to a plugin that was poorly written, out of date, or abandoned by whoever made it. In the most recent Patchstack security report, 91 percent of newly reported WordPress vulnerabilities were in plugins, and only six were in core itself.
Core WordPress, the software itself, has a strong track record. It’s reviewed heavily, patched quickly, and serious flaws in it are rare.
This one was in core
The 7.0.2 release fixed two problems that, chained together, let an attacker take over a site without logging in. No password, no account, no special plugin required. A plain default WordPress install was exposed.
In plain terms: someone could send a single anonymous request to a vulnerable site over the internet and end up running their own code on it (tracked as CVE-2026-63030). That’s about as serious as a web vulnerability gets.
The flaw was found by a security researcher and reported privately through WordPress’s bug bounty program, so it was fixed before it was public. Hosting companies and content delivery networks got a head start to patch their systems before the details went out. The disclosure process worked.
The lesson isn’t “don’t use WordPress”
It would be easy to read this as a reason to avoid WordPress. That’s the wrong takeaway.
Nothing connected to the internet is completely secure. Every platform, WordPress or otherwise, ships flaws eventually. Whether a site stays safe usually comes down to someone paying attention when the fix comes out, not to which platform it runs on.
The sites that get hurt by something like this are the ones nobody is watching: a site that got built two years ago, works fine, and hasn’t been touched since. It’s still online, still running old code, and there’s no one to notice when a critical update lands. A site sitting idle is quietly falling behind on the updates that keep it safe.
What actually keeps a site safe
Keep the site updated, and make a specific person responsible for doing it.
- Core, plugins, and themes stay current, and updates get applied quickly when a security release comes out
- Automatic updates are turned on where it makes sense, so critical fixes land without waiting on a human
- Backups exist and are tested, so there’s a way back if something does go wrong
- Someone is actually watching, instead of assuming a site that looks fine is fine
This 7.0.2 release is a good example of the system working. The flaw was serious, but it was caught, patched, and force-pushed to sites that had auto-updates on. The sites at real risk now are the ones running old versions with nobody home.
If your WordPress site is one you haven’t thought about in a while, the fix is simple: make sure it’s still getting updates, and that someone would notice if one didn’t land.
