Someone Bought 30 WordPress Plugins and Backdoored All of Them.

In early 2025, someone purchased a portfolio of 31 WordPress plugins on Flippa for a six-figure sum. The plugins covered everyday tools: countdown timers, popups, testimonials, FAQ widgets, sliders, and news displays. Hundreds of thousands of sites had them installed. The original developers had built the portfolio over nearly a decade.

The buyer’s first code commit was a backdoor.

Eight months later, on April 5 and 6, 2026, the payload activated. Hidden spam content began flowing to search engines across every site running any of the affected plugins. Site owners saw nothing. Their visitors saw nothing. Only Googlebot saw the spam. By April 7, WordPress.org had permanently closed all 31 plugins. The damage to affected sites’ search rankings was already done.

This is one of the most methodical supply chain attacks WordPress has ever seen and it raises a question the platform has not yet answered: what happens when trust itself is the vulnerability?

What Happened

The portfolio, known as Essential Plugin and originally built as WP Online Support around 2015, had grown to 31 free plugins with premium versions. By late 2024, revenue had fallen 35 to 45% and the original developers listed the business on Flippa. A buyer identified only as “Kris,” with a documented background in SEO, cryptocurrency, and online gambling marketing, acquired everything. Flippa published a case study about the deal in July 2025, by which point the backdoor had already been planted.

The buyer’s first SVN commit to WordPress.org, on August 8, 2025, introduced version 2.6.7 of the plugins. The changelog entry said “Check compatibility with WordPress version 6.8.2.” What it actually contained was 191 additional lines of PHP, including a PHP deserialization backdoor buried inside the plugins’ existing analytics module. The code sat idle for eight months, receiving no attention because it caused no visible problems.

On April 5 to 6, 2026, a command and control server at analytics.essentialplugin.com began distributing malicious payloads to every site running one of the affected plugins. The activation window was 6 hours and 44 minutes. WordPress.org permanently closed all 31 plugins on April 7. Security firm Patchstack published the full technical analysis on April 14.

How the Attack Actually Worked

The mechanics are worth understanding because they explain why it was so hard to detect.

The plugins’ internal analytics module phoned home to the attacker’s server and downloaded a file called wp-comments-posts.php. That name was deliberate: it closely resembles WordPress’s legitimate core file wp-comments-post.php. The rogue file then injected PHP code directly into wp-config.php, one of the most sensitive files in any WordPress installation.

The injected code fetched spam links, redirects, and fake pages from the attacker’s server. The critical detail: this content was served exclusively to Googlebot. Anyone browsing the site, including the site owner, saw a perfectly normal page. Search engines received cloaked content promoting gambling, cryptocurrency, and pharmaceutical keywords. This technique is called cloaking and it’s among the most dangerous SEO attacks because the victim has no idea it’s happening until Google penalises the domain.

The command and control infrastructure added another layer of resilience. Rather than pointing to a fixed domain that could be blocked, the malware resolved its command and control server through an Ethereum smart contract. Every time a server was taken down, the attacker could redirect traffic to a new one simply by updating the blockchain contract. Standard security takedowns don’t work against that design.

Why Nobody Noticed for Eight Months

Three reasons, and all three are structural rather than accidental.

The attacker was patient. Planting the backdoor in August and not activating it until April gave the malicious version eight months to accumulate automatic updates. Site owners who trusted the plugin updated to the infected version without any reason for suspicion.

The payload was invisible to humans. Spam content only appeared to Googlebot. Anyone checking their own site saw a normal page. The only signals were hidden in server logs and Google Search Console data, places most site owners never examine without a specific reason.

WordPress has no mechanism to flag plugin ownership changes. When the Essential Plugin portfolio transferred to the new buyer, no alert went out to users. No additional code review was triggered. The new owner inherited the previous developers’ commit access, their reputation, and the implicit trust of every site administrator who had automatic updates enabled. As far as WordPress.org was concerned, nothing significant had changed.

The Second Attack the Same Week

The Essential Plugin incident was not isolated.

The same week, Smart Slider 3 Pro, a plugin with more than 800,000 active installations, was separately compromised through a different route: its update server infrastructure rather than a portfolio acquisition. Two independent supply chain attacks on WordPress in the same seven-day period, both exploiting trust in the official update channel.

Security researchers noted this was the second time in recent months that blockchain-based command and control infrastructure had been used in a WordPress supply chain attack, suggesting either a shared playbook or a shared threat actor across incidents.

The Governance Problem Nobody Has Fixed

WordPress powers around 43% of all websites on the internet. Its plugin ecosystem has more than 60,000 plugins, many maintained by solo developers or small teams who may sell their work when revenue declines, interest fades, or they simply move on. The Essential Plugin portfolio was listed on Flippa because revenue had fallen nearly 40%. That’s a completely normal business situation.

The problem is structural. When a plugin business changes ownership, the old reputation transfers with it. Every site that has the plugin installed, and has automatic updates enabled, will receive whatever the new owner pushes. There’s no trust reset. No ownership disclosure. No additional scrutiny.

WordPress.org shut the plugins down quickly once the attack was discovered. But eight months had already passed between the backdoor being planted and being caught. The forced update to version 2.6.9.1 neutralised the command and control communication, but it did not remove the injected code already sitting in wp-config.php files across compromised sites.

The honest assessment: this attack model is repeatable. Any established plugin with a tired developer who wants to sell is a potential acquisition target for the same approach. Buy trust, wait, weaponise. Until WordPress introduces formal review of plugin ownership transfers and change of control notifications for users, the structural gap remains open.

What to Check If You Ran Any of These Plugins

The 31 affected plugins include Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, WP Team Showcase and Slider, Responsive WP FAQ with Category, SP News and Widget, WP Blog and Widgets, Post Grid and Filter Ultimate, and Hero Banner Ultimate among others. If any were active on your site between August 2025 and April 2026, treat the site as potentially compromised until confirmed otherwise.

Check for these two indicators:

1. A file called wp-comments-posts.php in your WordPress root directory. Note the extra ‘s’ compared to the legitimate wp-comments-post.php. If this file exists, delete it immediately.

2. Unusual code in wp-config.php near the require_once call for wp-settings.php. If your wp-config.php is running around 6KB larger than expected, it may have been injected with malicious code.

Updating or removing the plugin is not enough. The malicious code was injected into wp-config.php and stays there even after the plugin is removed. Manual cleanup of wp-config.php is required. If you’re not comfortable editing that file directly, contact your host’s support or a WordPress security specialist. After cleanup, rotate all admin credentials: WordPress admin, hosting control panel, FTP, and database passwords.

Restoring from a backup is the cleanest option if you have one from before August 8, 2025. Our guide to backing up a WordPress site covers setting up proper long-term retention so you have recovery options in situations exactly like this.

What This Means for WordPress Site Owners

This attack doesn’t mean you should stop using plugins. WordPress without plugins isn’t WordPress. But it does suggest a few habits are worth developing.

Know who maintains your plugins. A plugin from an identifiable team with a public track record carries less risk than one from a pseudonymous developer with no visible history. Yoast, Wordfence, and WooCommerce have identifiable teams and internal review processes. A portfolio of 31 plugins sold anonymously on Flippa does not.

Think twice about automatic updates for everything. For security patches, automatic updates are generally the right call. For major version changes from plugins with recent ownership changes or limited public history, a brief manual review before updating is worth the few minutes it takes.

Keep backups with long retention. Eight months passed between this backdoor being planted and being caught. A 30-day backup window is not enough. Aim for 90 days minimum on any site you care about.

Consider what managed hosting actually provides. One practical benefit of managed WordPress environments from providers like Kinsta, Rocket.net, and SiteGround is active malware scanning at the infrastructure level. Several managed hosts had flagged the Essential Plugin compromise in their security monitoring before most site owners were aware of the incident. That’s a real difference when the attack is designed to be invisible to the site owner.

Frequently Asked Questions

Which plugins were affected? The 31 permanently closed plugins all came from the Essential Plugin author account on WordPress.org. The most widely installed include Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, WP Team Showcase and Slider, Responsive WP FAQ with Category, SP News and Widget, Post Grid and Filter Ultimate, Hero Banner Ultimate, and WP Blog and Widgets. The full list was published by Patchstack on April 14, 2026.

How do I know if my site was compromised? Check for a file called wp-comments-posts.php in your WordPress root directory and look for unexpected code in your wp-config.php near the require_once line for wp-settings.php. If your wp-config.php is significantly larger than expected, inspect it carefully. You can also check Google Search Console for any manual actions or unusual search appearances on gambling, crypto, or pharmaceutical keywords.

Is updating the plugin enough to fix it? No. The forced update to version 2.6.9.1 cut the connection to the command and control server but did not remove the injected code from wp-config.php on already-compromised sites. Manual cleanup of wp-config.php is required to fully remove the infection.

What is a supply chain attack? A supply chain attack targets trusted software distribution channels rather than attacking individual sites directly. Instead of hacking your site, the attacker compromises a plugin or update mechanism you trust, and your own update process delivers the malware. It’s effective precisely because the infection arrives through a channel you’ve explicitly trusted.

Will this happen again? Until WordPress introduces formal review of plugin ownership transfers and change of control notifications for users, the structural conditions that made this attack possible remain in place. The same week as the Essential Plugin incident, Smart Slider 3 Pro was also compromised through a different route. This is not a one-off. Established plugins with declining revenue and anonymous ownership changes are a repeatable attack vector.