It is easy to run WordPress and assume you are fine. More than 40% of the internet runs on it, and that kind of scale tends to read as proof the platform has been stress-tested into stability. A recent supply chain breach has exposed that assumption as a serious liability.
On April 5th and 6th, 2026, a backdoor that had been sitting quietly in the update channel of 31 trusted WordPress plugins since August 2025 woke up. WordPress.org pulled all 31 plugins off the directory on April 7th. By then, thousands of sites had already been running a PHP deserialization backdoor for eight months. The attacker did not exploit a CVE. They did not phish a developer. They bought the plugins. On Flippa. For six figures. First commit after the ownership transfer was the malware.
This is not a WordPress bug. This is what WordPress is.
What actually happened
The plugins belonged to a portfolio called Essential Plugin, run by a developer who listed the whole business for sale on Flippa in early 2025. A buyer calling himself "Kris," with a public background in SEO, crypto, and online gambling marketing, bought the entire catalog.
On August 8th, 2025, all 31 plugins shipped version 2.6.7 with a changelog that read "Check compatibility with WordPress version 6.8.2." Inside that release were 191 extra lines of PHP that nobody noticed. The code included a deserialization primitive, an unauthenticated REST endpoint that accepted arbitrary PHP, and a command-and-control resolver that pulled its current domain from an Ethereum smart contract so the attacker could rotate infrastructure without pushing another update.
Then it sat there. For eight months. Accruing auto-updates, five-star reviews, and trust. On April 5th and 6th, 2026, it activated. It started injecting cloaked SEO spam into wp-config.php, serving different content to Googlebot than to human visitors, and hosting the REST endpoint as a ready-made webshell.
The victim plugins included names you would recognize on any small-business WordPress stack: Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, WP Team Showcase and Slider, Responsive WP FAQ with Category, Hero Banner Ultimate, Post Grid and Filter Ultimate. The kind of plugins a freelancer installs in the first hour of a build and never thinks about again.
The attack vector was trust, not code
You can patch a buffer overflow. You cannot patch the fact that a plugin's GitHub repo quietly changed hands, the original author signed off, and version 2.6.7 looks exactly like 2.6.6 plus a compatibility note.
Every layer of defense a typical WordPress site relies on failed here:
- WordPress.org review only screens the initial submission. Subsequent updates roll out automatically.
- Auto-updates, the single most-recommended WordPress security control, was the delivery mechanism.
- Security plugins (Wordfence, Sucuri, iThemes) did not flag 2.6.7 because the signature of "new PHP function you have never seen" is indistinguishable from "new feature" on a plugin under active development.
- Site owners had no meaningful way to evaluate the change. "Check compatibility with WordPress version 6.8.2" is exactly what a legitimate maintenance release looks like.
This is the same pattern I wrote about in the npm supply chain attack post, with one critical difference. In npm, lock files and npm ci give you a real defense: pin the version, and a compromised update cannot reach production until someone explicitly bumps the lock. WordPress has no equivalent. The plugin directory, auto-updates, and site health nags all push in the opposite direction. If you turn auto-updates off, the next security advisory becomes the thing that bites you.
You are choosing between two failure modes. That is the product.
The part nobody wants to say about XML-RPC
xmlrpc.php has been shipping in every WordPress install since 2004. It exists to let you publish from old desktop blog clients nobody has used since Windows Vista. It is still enabled by default.
What that default exposes has been documented for a decade. Unauthenticated username enumeration. Batched password brute force that can try close to two thousand credentials in a single HTTP request through system.multicall. A pingback mechanism that doubles as a blind SSRF primitive against internal network targets. The WordPress response to every one of those findings has been the same: "disable it at the web server level if you don't need it." That advice has been in the Codex, in countless blog posts, in every hardening guide. And the default is still "on."
In 2026 that default is the problem, because the people scanning for it are no longer humans.
The AI-agent multiplier is the real inflection point
Anthropic's Mythos-class models are on the immediate horizon, and the frontier labs have plenty of company in that race. Open-weights releases are tracking the same curve, and state-level actors have their own pipelines. Whatever the legitimate use cases look like, rogue actors are sizing up the same capabilities as a weapon, and the public web is the test environment.
Put that next to millions of outdated WordPress installs and a plugin directory that just proved it has no meaningful defense against ownership-transfer supply chain attacks, and the ceiling on what a single campaign can touch gets very high, very fast.
"But we use a managed host / WAF / security plugin"
Every time I bring this up, one of these four defenses comes up. Let me work through them honestly.
Managed WordPress hosting (WP Engine, Kinsta, Pantheon). These are excellent at keeping WordPress core patched and blocking obvious malicious traffic at the edge. They had zero visibility into the Essential Plugin backdoor because the backdoor came in through signed updates from the official plugin directory. The host trusted the source. So did everyone else.
A WAF (Cloudflare, Wordfence, Sucuri). Pattern-based WAFs match on request shapes. An unauthenticated REST endpoint that accepts a base64-encoded payload and deserializes it looks identical to any legitimate plugin's custom REST API. The false-positive rate of blocking it generically would break half the WordPress ecosystem.
A security plugin. Wordfence Premium is genuinely good. It still trusts WordPress.org as the source of truth for plugin integrity. When WordPress.org serves a backdoored release, the security plugin's integrity check passes.
"We have SOC 2." SOC 2 will ask whether you have a vendor-review process. Your answer for WordPress plugins is usually "we trust the plugin directory." Auditors have been signing off on that answer for a decade. They will stop.
None of this is the host's fault or the WAF vendor's fault. The structural problem is that WordPress sites outsource trust to a plugin directory that has no meaningful defense against ownership-transfer supply chain attacks, and the site owner has no practical mechanism to validate an update before auto-apply ships it.
Where I would actually move
The honest answer depends on what the site is for. I have watched enough WordPress installs get pwned, and helped enough people move off, to have strong opinions on where each kind belongs.
Content-heavy marketing sites with non-technical editors. Umbraco if you are already on .NET, Payload or Sanity if you are on Node. All three keep the CMS admin separate from the public render, which shrinks the attack surface to "the CMS API" instead of "every page of your site." The CMS binds to an internal address. The public site is static or server-rendered from a trusted build pipeline.
Portfolio and personal sites. A static generator with MDX content. This very site runs on TanStack Start with content collections. The attack surface of a pre-rendered HTML page is the attack surface of your CDN. There is no PHP process, no database, no admin panel, and no plugin directory to poison.
E-commerce. Shopify for anything below 50 million in revenue. BigCommerce if Shopify's customization model does not fit. A headless commerce stack (Medusa, commercetools) for teams that can staff it. WooCommerce on WordPress inherits every problem I just described, and then adds payment card data to the blast radius.
If you genuinely cannot move. Disable XML-RPC at the web server level, not with a plugin. Pin plugin versions and disable auto-updates. Assign a specific person to review every plugin changelog within 24 hours of release. Run Semgrep against every plugin you install before activation. Put the admin behind VPN or client-cert auth. Back up daily, restore-test quarterly. Assume compromise, and design your incident response around it. This is the posture worth running if you have legitimate reasons to stay, and it costs real money to maintain. It is not the default, and it cannot be made the default.
The sentence I keep coming back to
WordPress powers something north of 40% of the web. That number is often cited as an argument for its legitimacy. I read it the other way. It is the single largest, most uniform, most plugin-dependent attack surface on the public internet, and it is about to meet the first generation of attackers for whom "scan everything, try everything, chain everything" is cheap.
The Flippa backdoor is not an anomaly. It is a preview. Somebody already figured out that you do not have to exploit WordPress, you can just buy your way in, and the trust model breaks open the moment you do. Agentic AI is about to industrialize the rest.
If you run a WordPress site, this is the conversation to have with your stakeholders this quarter. Not next year.