WordPress Just Patched a Critical Flaw. 'It Updates Itself' Is Not the Same as 'I Am Protected.'

Everyone assumes WordPress updates itself, so a critical security patch is somebody else's problem to worry about. Reviewing the disclosure timeline this morning, that assumption looks a lot shakier than it did a week ago. WordPress shipped version 7.0.2 on 17 July 2026 to close a pre-authentication flaw in core, one that needs no account, no password and no plugin to exploit. The researchers who found it gave it a name: wp2shell.

That name matters less than what it did to the usual rules. Most WordPress vulnerabilities need a plugin nobody updated or a weak password somebody reused. This one lived in core itself, meaning a stock WordPress install with nothing else running on it was exposed. If you have ever told yourself "my site is too simple to be worth hacking," this is the exact scenario that argument does not survive.

What wp2shell Actually Is

wp2shell is not one flaw. It is two, chained together. The first, tracked as CVE-2026-60137, is a SQL injection in how WordPress core's WP_Query handles the author__not_in parameter. On its own, that is a data exposure risk. The second, CVE-2026-63030, is a route confusion bug in the REST API's batch endpoint at /wp-json/batch/v1. On its own, that is a lower-severity oddity.

Chained together, according to the researchers at Searchlight Cyber who discovered and reported them, the pair lets an anonymous attacker execute code on the server. No login screen to guess. No plugin vulnerability to scan for. Just a default WordPress installation and a working exploit chain. WordPress's own advisory rates the combined chain as critical, and the fix landed in 7.0.2 for the 7.0 branch, 6.9.5 for the 6.9 branch and 6.8.6 for the 6.8 branch, where only the SQL injection component applied.

So what does that mean if you are not the one reading CVE numbers for a living? It means the usual advice, "keep your plugins updated and use a strong password," was never going to save you from this one. The vulnerability sat underneath all of that, in the software every WordPress site runs regardless of what is built on top of it.

Why "It Updates Itself" Does Not Always Mean "It Updated"

Here is the myth I want to take apart, because I hear a version of it from business owners fairly often: WordPress has automatic background updates, so surely the important ones just happen without anyone needing to do anything.

Sometimes that is true. WordPress does support background updates for security releases, and given the severity here, the WordPress security team enabled forced updates through that system for sites capable of receiving them. But "capable of receiving them" is doing a lot of work in that sentence. Background updates depend on the hosting environment having the right file permissions, on the setting actually being switched on, and on nothing else on the site quietly blocking the process.

That last point is the one people forget. A fair number of site owners disable automatic updates at some point, usually after one update broke a page builder or a booking plugin and they got burned once. They flip the switch off to stop it happening again, and then never revisit that decision. Picture a physiotherapy clinic in Mullingar taking online booking deposits through its WordPress site. Eight months ago an update knocked out their appointment calendar for an afternoon, so the owner switched off automatic updates rather than risk it again. Nobody has looked at the version number since. That is not a hypothetical failure mode. It is the default outcome of a sensible-sounding decision made once and never checked again.

I made a version of that mistake myself early in the business, treating a "routine-looking" changelog as safe to leave until Monday. It was not routine. I do not queue security patches over a weekend anymore, whatever the changelog says.

If you are running a large deployment with a dedicated security team watching CVE feeds as their actual job, none of this is news to you. You likely patched within hours of the advisory going public. But that is not most people running a single WordPress site for their business, and it should not need to be.

The 24-Hour Window That Used to Be Weeks

What makes this particular release worth paying attention to, beyond the severity rating, is how fast it moved. WordPress shipped the patch on 17 July. Searchlight Cyber published its technical write-up the same day. By 18 July, a working proof-of-concept exploit had appeared publicly on GitHub, and CVE identifiers were formally assigned. BleepingComputer's coverage of the public exploits landed the same day, with the plain advice to patch now rather than later.

That is roughly a day between "here is the patch" and "here is working attack code anyone can run." Historically, that gap has often run to weeks, giving site owners more breathing room. It is compressing. So what does that mean in practice? Automated scanning tools do not care how small your business is or how unlikely a target you feel. They work through ranges of IP addresses and domains looking for whichever version number answers back. Being small does not make you invisible to a script. It just means nobody notices you have been hit until a customer mentions the site looks strange, or a Google Search Console warning turns up weeks later.

Four Things Worth Checking Today

None of these require a developer. They take a few minutes each, and they matter more this week than most weeks.

Verify. Log into your WordPress dashboard, go to Updates, and read the version number. You want 7.0.2, 6.9.5 or 6.8.6 depending on which branch you were on. If it says anything older, you are still exposed.

Confirm auto-updates are genuinely on. Do not assume the toggle is where you left it. Check the setting directly, because plenty of sites have it disabled from an earlier, unrelated decision.

Deploy the update if it has not already landed. From the dashboard, Updates, then Update Now. If your host manages this centrally, ask them to confirm the version rather than taking "we handle updates" as an answer on its own.

Take a backup before you touch anything, if you are updating manually and are not certain your last backup is recent. A pre-update snapshot means a plugin conflict costs you a rollback, not a rebuild.

What a Patch Does Not Undo

One honest limitation worth naming here: updating WordPress closes this specific door going forward. It does nothing to remove an intruder who already walked through it before you patched. If an attacker exploited the flaw during the window between disclosure and your update landing, a webshell or a rogue admin account can sit there quietly, patch or no patch. Our guide to WordPress security and backups covers the fuller picture of layered protection, and automatic malware scanning is specifically the layer designed to catch what a version update alone will not. If you patched late, running a scan afterwards is not paranoia. It is the other half of the job.

There is also a legal dimension to this that catches people out. Ireland's vulnerability disclosure rules, which I covered in more detail when they came into force, place obligations on businesses depending on what a breach actually exposes, not just on whether you eventually patched. Our piece on EU vulnerability disclosure requirements walks through what that means if you do find evidence of compromise, because "we fixed it since" is not the same conversation as "nothing was ever exposed."

Where Managed Hosting Actually Earns Its Keep

This is the kind of week that separates managed hosting from hosting that merely uses the word. A host that just gives you server space leaves the patching decision entirely with you, version number and all. On Web60's managed WordPress infrastructure, the operations team tracks WordPress core security releases and verifies they apply across the platform, on top of server-level hardening, fail2ban intrusion prevention and automatic malware scanning that runs regardless of whether you remembered to check anything this week. Pre-update safety snapshots are taken automatically before changes apply, so a conflict costs minutes, not a weekend. None of that replaces knowing your own version number. It does mean the gap between "a critical patch exists" and "my site is protected" is smaller than it would be running the software alone on a box you manage yourself, which is a fair part of what €60 a year, all-inclusive, is actually buying.

The Takeaway

A critical flaw in software running roughly four in ten of the world's websites is not a small story, and it will not be the last one. What it should change is not your opinion of WordPress. It is the confidence with which you assume "it updates itself" means "I am covered." Check the version number today. It takes less time than reading this article did, and it is the one step in this entire story that only you can actually confirm.

Frequently Asked Questions

What is wp2shell?

wp2shell is the name given to a chained pair of vulnerabilities in WordPress core, tracked as CVE-2026-60137 and CVE-2026-63030. Together they let an attacker with no account and no password run code on a default WordPress installation. WordPress patched the flaw in version 7.0.2, released 17 July 2026.

Do I need a specific plugin installed to be at risk?

No. The vulnerability sits in WordPress core itself, not in a plugin or theme. A stock WordPress installation with no plugins active on an affected version is exploitable. Running fewer plugins does not reduce your exposure to this specific flaw.

How do I check if my WordPress site is already patched?

Log into wp-admin, go to Dashboard, then Updates, and check the WordPress version number shown. You need 7.0.2 on the 7.0 branch, 6.9.5 on the 6.9 branch, or 6.8.6 on the 6.8 branch. If your host manages updates for you, ask them to confirm the version directly rather than assuming.

Does this affect WooCommerce or other online stores specifically?

The vulnerability affects WordPress core regardless of which plugins run on top of it, so a WooCommerce store on an affected core version is exposed the same way any other WordPress site is. Stores handling customer and payment data have more to lose if an attacker gets in, which makes patching and backup verification a higher priority, not a different process.

Should I take my website offline until I patch it?

For almost every small business site, no. Updating to the patched version takes minutes and removes the vulnerability. Taking a site offline costs you trading time and still leaves the underlying problem unsolved until you update anyway. The one exception is if you have specific evidence of compromise, in which case isolating the site while you investigate is the right call.

Does Web60 handle this kind of update automatically?

Web60's operations team tracks WordPress core security releases and verifies they apply across the platform, backed by server-level security hardening, fail2ban intrusion prevention and automatic malware scanning. Pre-update safety snapshots are taken automatically, so if an update ever conflicts with something on your site, there is a fast way back.

What should I do if I think my site was already compromised before I patched?

Updating WordPress closes the vulnerability going forward, but it will not remove a backdoor an attacker may have already planted. Run a malware scan, check for unfamiliar admin accounts or files, and restore from a clean backup taken before the exposure window if you find anything suspicious.

Sources

WordPress 7.0.2 Security Release

Searchlight Cyber, "wp2shell: Pre-Authentication RCE in WordPress Core"

The Hacker News, "New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code"

BleepingComputer, "WordPress Core 'wp2shell' RCE flaws get public exploits, patch now"

NCSC Ireland, Cyber Security Guidance for Small Business