WP2Shell: Critical WordPress RCE Flaw Actively Exploited

Two critical vulnerabilities in WordPress Core, collectively known as WP2Shell, are being actively exploited right now. If your site is running WordPress 6.9.0 through 6.9.4, or 7.0.0 through 7.0.1, an attacker can take complete control of it without a login, without exploiting a plugin, and without any prior foothold on your server. A single HTTP request is all it takes.

Both CVEs (CVE-2026-63030 and CVE-2026-60137) carry a combined CVSS score of 9.8 out of 10, the near-maximum severity rating used by the security industry. The vulnerabilities affect a default WordPress installation with no additional software required, meaning there is nothing a careful site owner could have done through plugin management or configuration choices to avoid exposure. The attack surface is WordPress Core itself.

What an Attacker Can Do With a Single Request

The WP2Shell exploitation in the wild goes beyond simply gaining access. Attackers are using the vulnerabilities to deploy persistent webshells and install malicious plugins on compromised servers. A webshell is a file that gives an attacker ongoing remote access to your server, independent of WordPress itself, and once it is in place, patching the original vulnerability does not remove it. The attacker retains control even after you update.

This is the detail that makes WP2Shell more serious than a typical vulnerability. Many site owners assume that updating WordPress closes the door, but with WP2Shell, if exploitation has already occurred, the backdoor persists. The update prevents new attacks through this vector; it does not evict an attacker who is already inside.

Proof-of-concept exploit code is publicly circulating, and active exploitation attempts have been confirmed by security honeypots. Automated scanning tools are already probing sites at scale, and any unpatched installation is a target — this is live, confirmed exploitation, not a theoretical risk identified in a controlled environment.

The vulnerability is triggered when a persistent object cache is not in use. Most standard WordPress installations do not have a persistent object cache configured by default, which means the majority of affected sites are exposed without any unusual configuration on their part. Cloudflare has deployed detection rules to protect customers at the network level, but that protection only applies if your site sits behind Cloudflare and your installation was not already compromised before those rules went live.

Patching Is Not Optional — And Persistence Means Patching May Not Be Enough

The patched releases are WordPress 6.9.5 and 7.0.2, and the WordPress.org security team took the unusual step of enabling forced updates through the auto-update system for sites running the affected versions. If your site had automatic background updates enabled, it may have already received the patch. That “may” matters: forced updates depend on the site being reachable and the update process completing without error, and hosting configurations, caching layers, and maintenance mode settings can all interrupt an automatic update silently.

The first thing to do is verify the WordPress version in your dashboard. Log in, go to Dashboard, then Updates, and confirm the version number shown. If it reads anything other than 6.9.5 or 7.0.2 (depending on your release branch), the update has not applied and you need to act immediately.

If you manage the site yourself, the update process is:

1. Back up the database and all files before making any changes
2. Apply the update through Dashboard, then Updates, then Update Now
3. Confirm the version number after the update completes
4. Check that automatic background updates are enabled in your settings

If you use a managed hosting platform, contact your host directly and ask them to confirm which version is running and whether the forced update was applied successfully. Do not assume it was.

Checking the version number answers only part of the question. If your site was running an affected version before the patch was applied, and if it was publicly reachable during that window, you cannot rule out prior exploitation. A determined attacker will conceal their presence, so the absence of obvious signs is not reassurance. Look for unfamiliar plugins appearing in your plugin list, new administrator accounts you did not create, unexpected files in your WordPress directories, and outbound connections from the server to unfamiliar addresses.

Even if your version number now shows 6.9.5 or 7.0.2, a post-patch check is worth doing. Update the software, then look for evidence that someone was already there.

One consequence that rarely gets discussed in these situations is the downstream effect on trust. Search engines, particularly Google, actively scan for signs of site compromise, and a site serving malicious content, redirecting visitors, or hosting injected links can be flagged and removed from search results. Recovering that ranking position takes time measured in weeks or months, not days, and the business cost of that outcome extends well beyond the technical remediation.

---

If you are not certain your WordPress installation is running 6.9.5 or 7.0.2, or if you want a post-patch review to check for signs of prior compromise, I offer a focused WP2Shell security audit through The WordPress Guy. Given that webshells persist after patching, the window for catching a compromise before it causes lasting damage is short. Book a security audit and I will verify your version, check your update configuration, and examine the site for indicators of exploitation.