Short answer: In 2025, someone bought a bundle of more than 30 WordPress plugins on Flippa, the marketplace for online businesses. They shipped one quiet “compatibility” update that hid a backdoor, let it sit for about eight months while sites kept installing it, then switched it on in early April 2026. The scary part isn’t the code — it’s that the plugins didn’t change. Their owner did, and nobody told the sites running them.
We run managed hosting and watch this kind of thing for client sites, so here’s the plain-language version — with links to the people who actually dissected it, not to blog re-tellings.
What happened, in order
The plugins were the Essential Plugin portfolio — a fading set of small utilities (popups, countdown timers, sliders) with more than 20,000 active installs between them by WordPress.org’s own count; the vendor itself advertised over 400,000 installs and 15,000 customers. In 2025 the whole bundle was sold on Flippa for an undisclosed sum to a buyer known only by the alias “Kris.”
Then the trap was laid, slowly:
| When | What happened |
|---|---|
| 2025 | The 30+ plugin bundle is sold on Flippa to a new owner |
| 8 Aug 2025 | Version 2.6.7 ships. Changelog: “Check compatibility with WordPress version 6.8.2.” It actually adds 191 lines of PHP — a hidden deserialization backdoor |
| About 8 months | The code sits dormant. Sites install and auto-update it, trusting a plugin they’ve run for years |
| Early Apr 2026 | The backdoor is switched on remotely and starts injecting malware |
| 7 Apr 2026 | WordPress.org’s plugin team confirms the attack, force-updates the fix, and pulls every affected plugin from the directory |
The dormancy is the clever, cynical part. A brand-new plugin with a backdoor gets caught fast. A plugin you’ve trusted for three years, that quietly updates itself overnight, does not.
The weapon was disguised as “analytics”
When it activated, the plugins phoned home to analytics.essentialplugin.com — an innocuous-sounding “analytics” subdomain — and downloaded a file called wp-comments-posts.php onto the site. That file then wrote about 6 KB of PHP straight into wp-config.php (it grew from 3,345 to 9,540 bytes), one of the most sensitive files in any WordPress install. From there the attacker could write arbitrary files: spam pages, redirects, more malware.
You didn’t click anything. You didn’t get phished. The call was coming from inside the house — from software you installed on purpose.
It was caught by a backup
The forensic timeline came from Anchor Hosting, which keeps daily restic backups. They pulled wp-config.php from several backup dates, compared the file sizes, and pinned the active injection window to 6 April 2026, between 04:22 and 11:06 UTC — six hours and forty-four minutes. Without versioned backups, that injected code just looks like part of your site.
That’s the quiet lesson here: good backups aren’t only for restoring after a disaster. They’re also the only honest record of what your site looked like before something changed it.
So who actually got hit?
Here’s the part most headlines skip. No one has published a confirmed count of sites that were actually infected, and no named victims have come forward. What’s documented is the exposure, not a body count.
And the exposed sites were ordinary ones. These plugins — popups, countdown timers, logo and post sliders — are the small, forgettable utilities that small-business shops, blogs and brochure sites install once and never think about again. Not hardened enterprises with a security team; the long tail of normal websites.
But exposure isn’t infection. The active window was under seven hours, and WordPress.org force-pushed a fix the next day. The sites that actually took the 6 KB of malicious PHP into their wp-config.php were the ones running an affected plugin that happened to check in during that window — and for them, the attacker could write arbitrary files: spam pages, hidden redirects, more malware, and from there potentially deeper into the site.
The victims no one is counting are the abandoned sites. A forced update only reaches sites still talking to WordPress.org; a site nobody logs into — the kind whose developer quietly moved on — can still be carrying the backdoor today. The short, loud window is the part that got reported. The long, silent tail is the part that worries us.
The hole nobody could patch: who owns your plugins?
Here’s what makes this attack different from the usual “update your plugins” advice. There was no coding bug to find. The plugins were fine. What changed was who controlled them — and, as Anchor put it, “WordPress.org has no mechanism to flag or review plugin ownership transfers. There is no ‘change of control’ notification to users.” Patchstack, the security firm that dissected the code, confirmed the backdoor in more than 20 of the plugins.
So a stranger can buy the plugin behind your contact form, your cookie banner or your countdown timer — and the first you’d hear of it is when your site starts serving spam.
What this actually means for a business owner
You can’t personally audit who quietly bought every plugin on your site. But the risk shrinks fast with a few habits:
- Run fewer plugins. Every one is a small company that could be sold tomorrow. The plugin you installed once and forgot is the dangerous one.
- Notice what changes. Unexpected overnight updates, files you didn’t create, a
wp-config.phpthat grew for no reason — these are signals, if someone is watching. - Keep off-site, versioned backups — not on the same server, and not just “enabled.” They’re your restore and your evidence.
- Watch the security feeds. When something like this breaks, the gap between “disclosed” and “patched on your site” is where the damage happens — see where to check, for free, which holes threaten your site.
Where we come in
Most of this is what managed hosting quietly does: keep the plugin count lean, watch for file changes that shouldn’t be there, keep tested off-site backups, and track advisories so a story like this turns into a five-minute fix instead of a weekend of cleanup. Your site is yours — but somebody should be watching what software runs on it, and whether it still belongs to who you think it does. That’s the job. (If your site was built and then handed off to nobody in particular, start here: the developer disappeared — who’s watching the site now?)