Originally published at https://monstermegs.com/blog/wordpress-core-vulnerability/
Tens of millions of WordPress sites went to bed secure and woke up exploitable. On July 17, 2026, the WordPress security team shipped an emergency patch for a WordPress core vulnerability so severe that an anonymous visitor could seize full control of a site without ever logging in. Attackers were already using it. If you run a WordPress site and have not updated in the past week, this is the news that should pull you away from everything else on your list today.
Dubbed wp2shell by the researcher who found it, this WordPress core vulnerability chains two separate flaws into a single unauthenticated path to remote code execution. It affects a bare install with zero plugins, which is exactly what makes it so dangerous. There is nothing exotic about the sites at risk; ordinary blogs, shops, and business pages are all in scope. Here is what happened, how the exploit works, and the short list of actions that actually protect your site.
Inside the wp2shell WordPress Core Vulnerability
The WordPress core vulnerability was disclosed on July 17, 2026, when the project released versions 7.0.2 and 6.9.5 alongside a back-ported fix for 6.8.6. Security researcher Adam Kues of Searchlight Cyber discovered the issue and reported it privately before public disclosure. WordPress urged site owners to update immediately and enabled forced updates across installations where the auto-update system was available.
What sets this WordPress core vulnerability apart from the steady drip of plugin bugs is its location. The flaw lives in WordPress core itself, the software every self-hosted site runs, rather than in a third-party add-on you might not even have installed. There is no way to opt out by keeping a lean plugin list, which is why the disclosure landed with real force across the hosting world.
How the Attack Chain Works
The wp2shell exploit is not one bug but two, chained together. On their own, each is serious. Combined, they hand an attacker the keys to the server, and the researchers who mapped the chain showed how little effort a working exploit actually took.
The SQL injection flaw
The first link is CVE-2026-60137, a SQL injection vulnerability rated high severity that affects WordPress 6.8 and later. SQL injection lets an attacker manipulate the database queries WordPress runs by feeding the application crafted input. On its own, this WordPress core vulnerability could expose usernames, hashed passwords, and other sensitive data stored in the database.
The REST API batch route confusion
The second link is CVE-2026-63030, a critical unauthenticated remote code execution flaw affecting WordPress 6.9 and later. It abuses the REST API batch endpoint when persistent object caching is disabled, which is the default on many sites. Chained with the SQL injection, it lets an anonymous request run code on the server with no login and no user interaction required. That combination is why the WordPress core vulnerability earned a critical rating.
Why Millions of Sites Remain Exposed
Scale is what makes this WordPress core vulnerability a genuine internet-wide event. WordPress powers a large share of the web, and not every site updates quickly or automatically. That gap between released patch and applied patch is where the damage happens, and it widens on sites that disabled updates to avoid breaking a fragile theme or plugin.
According to TechCrunch, more than 400 million WordPress websites were running vulnerable versions when the fix landed. Security consultant Daniel Card estimated that fewer than 15 percent were actually exploitable, which still leaves roughly 90 million sites at risk. Automattic said properties on its own platform were protected even before the release and that fixes were deployed across millions of sites at once. Self-hosted sites without auto-updates are the ones left exposed to this WordPress core vulnerability.
How WordPress and Security Firms Responded
The response to the WordPress core vulnerability was fast and coordinated. Cloudflare deployed two web application firewall detection rules on July 17, 2026 at 17:03 UTC, protecting free and paid customers with a block action by default. As Cloudflare put it, firewall protections reduce exposure while customers update, but they are not a substitute for patching. The message from every vendor was identical: patch first, filter second.
Security firms including Patchstack, Hexastrike, and WatchTowr confirmed active exploitation in the wild within days of disclosure. The gap between patch release and mass exploitation was measured in hours, not weeks, which is the defining feature of this WordPress core vulnerability and the reason security teams treated it as an emergency rather than routine maintenance.
The Wider Security Picture Around the Disclosure
The wp2shell fix did not arrive in isolation. In the same window, WordPress pushed forced auto-updates, hosting providers folded emergency patches into their control panels, and security vendors published detection signatures within hours. Patchstack added virtual patching rules, and independent researchers released indicators of compromise so administrators could search their own logs for early probing. The coordinated cadence shows how much the ecosystem has matured since earlier core incidents, when advisories often trickled out over days and left owners guessing.
Context from adjacent advisories mattered too. Cloudflare noted that the remote code execution path only fired when persistent object caching was disabled, a detail that let some large hosts confirm their fleets were already shielded. That kind of specificity turns a frightening headline into an actionable checklist, and it is why reading the primary advisory beats reacting to a secondhand summary. Anyone still running this WordPress core vulnerability on an unpatched host should treat those indicators as the starting point for a proper review, not the finish line.
What This WordPress Core Vulnerability Reveals About Update Habits
The wp2shell episode confirms a pattern the security community has warned about for years. Attackers reverse-engineer patches the moment they ship, then race to hit sites before administrators apply the update. This WordPress core vulnerability compressed that window to almost nothing, turning a routine version bump into a same-day emergency for anyone paying attention.
It also punctures a comforting myth, the idea that a lean site with few plugins is inherently safe. Because this WordPress core vulnerability lives in core, a minimal install was just as exposed as a plugin-heavy one. Your attack surface is not only your add-ons; it is the platform itself. We saw a related lesson during the recent plugin vulnerability wave, but this time the fix could not come from simply deleting an extension.
Fast, well-managed hosting matters here too. Servers that apply updates promptly and run current PHP and caching standards shrink the window in which a WordPress core vulnerability can be weaponized. This is one reason MonsterMegs runs LiteSpeed and keeps its stack patched and current, so the time between a fix and its deployment stays short.
What to Do About the WordPress Core Vulnerability Now
If you take one action from this news, make it this: update WordPress to 7.0.2, 6.9.5, or 6.8.6 today. Log in, open your Dashboard, and confirm the running version. If auto-updates are enabled, verify the patch actually applied rather than assuming it did, because a stalled update leaves you exposed to the same WordPress core vulnerability you thought you had closed.
Next, check for signs of compromise. Look for unfamiliar admin accounts, unexpected scheduled tasks, or modified core files. If your site sat on a vulnerable version and faced the internet between July 17 and your update, treat it as potentially breached and scan it thoroughly. A firewall gave you a buffer, but it was never a patch, and attackers who slipped in before you updated will not remove themselves. Document what you find so you can prove the timeline later if it matters.
Finally, harden the basics that blunt the next WordPress core vulnerability before it arrives. Enforce strong admin passwords, keep current off-server backups, run a supported PHP version, and limit who can reach sensitive endpoints. Our past coverage of server-side hardening applies directly to the habits that keep a site resilient between disclosures.
The Takeaway
The wp2shell disclosure is a reminder that WordPress core vulnerability response is now a race measured in hours, not days. Patch immediately, verify the update actually landed, and scan anything that sat exposed. The sites that got hurt were not careless; many were simply slow. Speed of response is the whole game, and it starts with knowing your version tonight. Treat any older version as an open door until you confirm otherwise.
If you would rather your host handle timely updates and edge-level protection for you, our managed WordPress hosting keeps your stack patched, fast, and watched so the next emergency is one less thing on your plate.
Top comments (0)