Most WordPress security scares are about plugins. This one was not, and that is what made it rare. On July 17, 2026 the WordPress security team shipped an emergency fix for a flaw in WordPress’s own core code, a chain nicknamed wp2shell that let an attacker with no account take over a stock site. WordPress then did something it almost never has to do: it pushed the update out automatically, to millions of sites, without waiting for owners to act. And over the following 72 hours, the break-ins started anyway. We covered the flaw itself when it broke over the weekend. The more useful story now, for anyone who runs or hosts WordPress at scale, is what the days since have exposed: the gap between a fix being shipped and a site actually being safe.

Why This One Was Different From the Usual WordPress Scare

WordPress runs about 41 percent of all websites, so the platform produces a steady stream of security advisories, and almost all of them concern add-ons rather than the platform itself. Security firm Patchstack, which tracks the ecosystem, counted 11,334 WordPress vulnerabilities in 2025; 91 percent were in plugins, most of the rest in themes, and just six were in core, all minor. A serious flaw in core is the exception. An unauthenticated one, exploitable by a stranger against a default site with no add-ons, is rarer still. The last time WordPress core carried a comparable remote-takeover flaw was 2016, and even that lived in a third-party mail library bundled with WordPress rather than in WordPress’s own code. On the US government’s catalog of vulnerabilities confirmed to be under attack, every previous WordPress entry has sat in a plugin, never in core. wp2shell is the first that could change that.

WordPress Did the Rare Thing and Forced the Fix

Because the flaw sat in core, WordPress could push the fix to sites automatically. The platform delivers core security releases through its auto-update system, applying them without the owner clicking anything, and for wp2shell it turned that on across the affected versions. On a platform that powers a reported 500 million sites, most run by people who will never read a security advisory, automatic updating is the only realistic defense, and its existence is a genuine strength of WordPress. Security vendors moved in parallel: Cloudflare switched on blocking rules for every customer, including free accounts, within hours of disclosure, and Wordfence and Patchstack pushed their own protections. For a large share of sites, the fix arrived before the owner knew there was a problem.

An Unauthenticated Path to Code Execution in WordPress Core, Already Being Exploited

Then the Break-Ins Started Anyway

The protection was not universal, and attackers moved faster than the tail of unpatched sites could close. Working attack code appeared within a day, and by the Sunday after disclosure one tracker counted more than two dozen separate public exploits. By Monday, multiple security firms were reporting mass exploitation, the work not of one gang but of many using shared public tooling. The security firm watchTowr said it logged tens of thousands of attack attempts and more than a hundred hidden administrator accounts created across its sensors. Researchers described attackers stealing sites’ stored password databases, planting hidden backdoor files, and uploading malicious plugins to keep access even after a later cleanup. One watchTowr researcher put the speed plainly, saying that reproducing the attack from the public disclosure, with help from current AI models, was “only a matter of time and tokens.” The window between a flaw becoming public and it being exploited at scale has essentially collapsed.

Why a Forced Update Still Leaves Sites Exposed

A forced update is a probability across a fleet, not a guarantee for any single site, and several ordinary conditions quietly block it: an owner or host that turned automatic updates off, file permissions that stop WordPress writing to itself, managed platforms that pin a specific version, and heavily customized installs. WordPress has not published how many sites the push actually reached. The one solid measurement comes from security firm Wiz, which watched the share of internet-exposed vulnerable servers it tracks fall from 25 percent to 10 percent within a day of disclosure. That is fast, and it is also the whole point: the update and the firewall rules closed most of the exposure quickly, but the remaining tail did not vanish, and a tail of millions is still an enormous number of sites. Attackers concentrate on exactly the sites the automatic fix missed, because those are the ones still open.

Verify the Version, Then Hunt for the Breach

For a hosting provider, or anyone managing WordPress in bulk, wp2shell is a reminder that the automatic update is load-bearing infrastructure for a large part of the web, and also that it cannot be trusted blindly. Two things follow:

  • The deliverable is verification, not the update itself. Confirm the running version number on every site you are responsible for rather than assuming the push fired, because the sites where it silently failed are the ones that matter.
  • Any site that was slow to update has to be treated as possibly breached, not merely patched. Exploitation began within hours, and the attacks steal credentials and plant persistence, so inspect installations for new administrator accounts, unfamiliar plugins, and suspicious files regardless of whether they have been updated.

The forced push saved a great many sites this month. The ones it did not reach are now a cleanup problem, and finding them is the work that separates a managed platform from a pile of unattended installs.