The WordPress Plugin You Trusted Just Got Sold

On the morning of 6 April 2026, for a window of six hours and forty-four minutes, roughly twenty thousand WordPress sites started serving spam links to Google. The site owners saw nothing. Their dashboards were normal, their pages looked correct in a browser, their security plugins reported nothing. The spam was cloaked. It was only visible to Googlebot. And the reason it was there is that eight months earlier, someone had bought thirty WordPress plugins on Flippa, and one of the plugins on that shopping list was running on their site.

This post is about what happened, why the emergency response didn't clean up the mess, and what it changes about how you should pick and audit plugins in 2026.

What actually happened

The plugin publisher known on WordPress.org as essentialplugin (marketed as Essential Plugin) was, up until early 2025, run by its original developer. In the first half of 2025 the portfolio, a bundle of over thirty free WordPress plugins with a combined install base of roughly four hundred thousand sites, was sold on Flippa. A Flippa case study later described the deal as a six-figure exit. The SVN handover on WordPress.org went through in May 2025 to a buyer identified only as Kris.

For the next eight months, nothing happened. The plugins continued to work. Updates continued to ship. Anyone using one of them was, from every visible signal, being maintained by the same trusted publisher they'd installed years earlier.

On 6 April 2026, between 04:22 and 11:06 UTC, that changed. The plugins made an outbound request to analytics.essentialplugin.com, pulled down a payload, and installed a backdoor in a file named wp-comments-posts.php. The backdoor injected additional code into each site's wp-config.php. Then it served cloaked SEO spam to Google's crawler for the rest of that six-hour-forty-four-minute window. To a browser, or a security scanner running from a normal IP, the affected sites looked completely unchanged.

WordPress.org's Plugin Review Team caught it. On 7 April they closed all thirty-one affected plugins on the repository. On 8 April they force-pushed a cleanup version, v2.6.9.1, to every site running one of them. That should have been the end of the story. It wasn't.

Why the emergency update didn't clean your site

The cleanup version neutralised the phone-home. It stopped the plugin reaching out to analytics.essentialplugin.com for further instructions. It did not, however, touch wp-config.php. And it did not remove wp-comments-posts.php. Both of those had been written by the payload the first time it ran, and both of them stayed exactly where the attacker had put them.

For a site owner, this is the awkward part. If you were running one of the affected plugins in early April 2026, and you left auto-updates on and did nothing else, then as of today your site has:

The updated, clean plugin, no longer able to phone home.
A modified wp-config.php containing attacker code.
A file called wp-comments-posts.php in the root of your web directory.

Anyone reading a "your plugin was updated, you're safe" summary of the incident would have assumed the auto-update handled it. It didn't. The specific tell, according to Anchor Hosting's writeup by Austin Ginder, is a wp-config.php file that grew from around 3.3 KB to around 9.5 KB. Roughly six kilobytes larger than a normal WordPress installation would have. If your wp-config.php is significantly larger than that, and you had one of the affected plugins installed in April 2026, you have work to do.

This is the single most important detail of the whole incident. Forced auto-updates are useful. They aren't the same as remediation. Any incident where a compromise persists after the vulnerability is patched, and this is one, needs a manual pass over the file system.

Why this changes how you think about plugin trust

WordPress plugin trust signals are all lagging indicators. Install count, review score, "last updated" date, active maintenance flag on the repo. All of them measure the state of the plugin as a project, from data that's weeks or months out of date. None of them measure who currently controls the code. And ownership transfer is not surfaced to anyone. A plugin you installed in 2020 from a developer you'd read good things about can, in 2026, be run by anyone at all. You wouldn't know. There is no "ownership changed" notice on the plugin page. There is no email to installed sites. The SVN handover is a WordPress.org internal administrative event.

That matters because for an attacker, the calculus is very simple. Writing an exploit for a popular plugin is hard. Finding one that isn't already patched is harder. Getting your code onto four hundred thousand sites, in a form users will actively install and update to, is normally impossible. Unless you buy the plugin. Then it's the easiest thing in the world.

The specific thing that made this incident work is the eight-month gap. If the buyer had planted the backdoor on the first day, it would have shown up in the community's routine audits and the plugin would have been closed before the payload activated. By waiting eight months, running clean updates the whole time, they built up a trust window during which nobody was looking. That pattern is now public and reproducible. Anyone reading this can see the shape of the attack. So can the next attacker.

I don't want to overstate this. The vast majority of WordPress plugins are still run by the developers who wrote them. The vast majority of ownership transfers, when they happen, are boring and legitimate. But the vast majority of anything is not what security is about. Security is about the small fraction of cases where the boring assumption doesn't hold.

What to actually do

Two levels of response, immediate and ongoing.

If you were running one of the affected plugins in April 2026, or you don't know for sure that you weren't, check your wp-config.php file size. On the command line: ls -la wp-config.php. A standard WordPress wp-config.php is around three to four kilobytes. If yours is significantly larger, and you can't account for the extra content (no unusual constants, no custom code you or a developer added), assume compromise, restore from a backup that predates April 2026, and rotate every credential in the file. Also check the web root for a file called wp-comments-posts.php. That file does not belong in a standard WordPress installation. Delete it.

The affected plugins are listed in the Patchstack advisory and the Anchor Hosting writeup. Both are worth reading in full if this applies to you.

For every WordPress site you run going forward, the takeaway is that the auto-update-and-forget model was already looking thin, and this is the incident that finishes it off. That doesn't mean turn off auto-updates. It means auto-updates are one layer, not the whole strategy. The layers that matter now are:

Keep a record of what's installed on each site and who publishes it. Not for compliance. For the moment where a supply-chain incident lands and you need to know, quickly, whether you're exposed.
Watch the size and modification time of wp-config.php and the web root. File-integrity monitoring is not glamorous but it would have caught this in the first hour.
Assume any forced emergency update is the start of your response, not the end. Read the actual advisory. Check the specific file paths named in it.
Reduce your plugin count. Every plugin is a potential future ownership transfer. Every ownership transfer is a potential future incident. The plugins you don't have installed cannot betray you.

None of that is new advice. What's new is the case study.

Where this fits

The Protect My WP handbook is thirteen chapters on how to run a WordPress site so that when incidents like this land, and they will keep landing, the specific thing that saves you is already in place. Chapter 8 covers plugin and theme hygiene in detail, including the newer bit that the ecosystem is still catching up to: how to keep a running inventory of what's on your site, how to review new plugins before you install them, and how to spot the signs that something has changed under a plugin you were treating as stable.

If April 2026's Essential Plugin incident made you look at your plugin list differently, the handbook is the specific answer to "what do I do about this properly".

Get the book for £19.