Your WordPress Plugins Could Be Backdoored — And You’d Never Know

How a six-figure Flippa deal turned 31 trusted plugins into a global supply chain attack

In early April 2026, a sophisticated supply chain attack quietly activated across tens of thousands of WordPress websites worldwide. The method was methodical, the execution patient, and the target was trust itself — specifically, the trust site owners place in plugins they have run without incident for years.

This post explains what happened, who was behind it, what the malicious code actually did, and — most importantly — how to check whether any of your websites were affected.

We audited every WordPress install on our hosting platform on 21 April 2026. Here is what we found.

The Backstory: A Portfolio Sale That Nobody Flagged

The attack begins not with a hacker in a dark room, but with a legitimate business transaction.

A WordPress plugin developer known as WP Online Support — later rebranded as Essential Plugin — had spent nearly a decade building a portfolio of over 30 plugins: sliders, galleries, countdown timers, FAQ accordions, team showcases, testimonial widgets. Solid, unremarkable utility plugins with a combined install base in the hundreds of thousands. The kind of plugins that power thousands of small business websites without anyone thinking twice about them.

By late 2024, the original developer’s revenue had declined significantly. The business went up for sale on Flippa — a legitimate marketplace for buying and selling digital businesses. A buyer identified only as “Kris,” with a background in SEO, cryptocurrency, and online gambling marketing, purchased the entire portfolio for a six-figure sum. Flippa was pleased enough with the transaction to publish a case study about it in July 2025.

What nobody checked — because nobody had a mechanism to check — was what the new owner planned to do with 31 plugins and their direct update channel to hundreds of thousands of live WordPress websites.

The Backdoor: Hidden in Plain Sight for Eight Months

On 8 August 2025, the new owner pushed their first code update to the plugins. The changelog read:

“Check compatibility with WordPress version 6.8.2.”

That single, innocuous line concealed 191 additional lines of PHP code.

The malicious code was embedded inside an existing analytics module. A file called class-anylc-admin.php grew from 473 lines to 664 lines. To a casual reviewer, it looked like routine maintenance. To an automated security scanner looking for known malware signatures, it looked like nothing at all — because it was entirely new, purpose-built code.

How the backdoor worked:

• It registered an unauthenticated REST API endpoint — anyone on the internet could trigger it without logging in
• When triggered, it called out to the attacker’s server at analytics.essentialplugin.com
• It passed the server’s response directly into PHP’s unserialize() function — a classic deserialization vulnerability enabling remote code execution
• The attacker’s server controlled everything: the function to call, the arguments, the outcome

Then it sat there. Dormant. For eight months.

The Activation: April 5–6, 2026

At 04:22 UTC on 6 April 2026, the attacker’s server flipped. Instead of returning a benign response, it began serving malicious serialised PHP payloads to every WordPress site that had the plugin installed. The activation window lasted 6 hours and 44 minutes, ending at 11:06 UTC.

During that window, affected sites received instructions to:

1. Download a file called wp-comments-posts.php into the website root directory. Note the deliberate similarity to the legitimate WordPress core file wp-comments-post.php — one extra letter ‘s’, easy to miss.
2. Inject approximately 6 kilobytes of PHP code into wp-config.php — the WordPress configuration file — immediately before the line that loads WordPress itself.

The injected code fetched spam links, fake pages, and redirects from a command-and-control server — and served them exclusively to Googlebot, the search engine crawler. A human visiting the site saw nothing wrong. The site functioned normally. But Google’s crawler was being served hidden doorway pages designed to manipulate search rankings.

The command-and-control infrastructure had one more layer of sophistication: the domain it resolved to was stored in an Ethereum smart contract on a public blockchain. Take down the domain, and the attacker simply updates the contract — a new address is live in seconds.

Attack Timeline

Date	Event
Late 2024	Essential Plugin portfolio listed on Flippa by original developer
Early 2025	Buyer “Kris” (SEO/crypto/gambling background) purchases portfolio for six figures
12 May 2025	New essentialplugin WordPress.org account created with SVN commit access to all 31 plugins
8 Aug 2025	Version 2.6.7 pushed — changelog reads “Check compatibility with WordPress 6.8.2”; contains 191 lines of backdoor code
Aug 2025 – Apr 2026	Backdoor sits dormant. Attacker’s server returns normal responses. No anomaly detectable.
5–6 Apr 2026	Activation window: 04:22–11:06 UTC. Malicious payloads delivered. wp-config.php infected on affected sites.
7 Apr 2026	WordPress.org permanently closes all 31 plugins
8 Apr 2026	Forced update v2.6.9.1 disables phone-home — but does NOT clean already-infected wp-config.php files
21 Apr 2026	Com Technology audits all 22 WordPress installs on host.tkr.co.nz — zero infections found

The Response: Fast, But With a Critical Gap

WordPress.org’s plugin team moved quickly. On 7 April 2026, all 31 affected plugins were permanently closed. A forced update — version 2.6.9.1 — was pushed on 8 April that disabled the phone-home mechanism.

Critical gap: the forced update did not clean up what had already happened. Sites that received the malicious payload during the activation window still have the injected code in their wp-config.php. Updating the plugin to 2.6.9.1 stops future phone-home calls — it does not remove the existing infection.

The 31 plugins are permanently dead. They will never receive another update from WordPress.org. Running any of them — even the 2.6.9.1 version — means running software with no future security support.

What to Check: Indicators of Compromise

1. Check your plugin list against the 31 affected slugs

Log into your WordPress dashboard, go to Plugins, and check for any of the following. If you see one, remove it immediately regardless of version — these plugins are permanently dead.

Affected Plugin	Affected Plugin
Accordion and Accordion Slider	SP FAQ
Album and Image Gallery Plus Lightbox	Sliderspack — All in One Image Sliders
Audio Player with Playlist Ultimate	SP News and Widget
Blog Designer for Post and Widget	Styles for WP PageNavi Addon
Countdown Timer Ultimate	Ticker Ultimate
Featured Post Creative	Timeline and History Slider
Footer Mega Grid Columns	Woo Product Slider and Carousel with Category
Hero Banner Ultimate	WP Blog and Widgets
HTML5 Video Gallery Plus Player	WP Featured Content and Slider
Meta Slider and Carousel with Lightbox	WP Logo Showcase Responsive Slider
Popup Anything on Click	WP Responsive Recent Post Slider
Portfolio and Projects	WP Slick Slider and Image Carousel
Post Category Image with Grid and Slider	WP Team Showcase and Slider
Post Grid and Filter Ultimate	WP Testimonial with Widget
Preloader for Website	WP Trending Post Slider and Widget
Product Categories Designs for WooCommerce

2. Check your wp-config.php file size

A clean WordPress wp-config.php file is typically around 3–3.5 kilobytes. An infected one balloons to approximately 9.5 kilobytes. If you have server access, the file size is the fastest indicator. Open the file and look for unusual PHP code near the bottom — particularly anything referencing Googlebot.

3. Check for the dropped backdoor file

In your website’s root directory, look for a file called wp-comments-posts.php (with a trailing ‘s’). The legitimate WordPress core file is wp-comments-post.php — without the ‘s’. The extra ‘s’ is the malicious file. If it exists, delete it immediately.

4. Check whether your site is serving hidden spam to search engines

The malware only shows its payload to Googlebot. If your site was infected, a real visitor sees nothing wrong. To check, simulate a Googlebot visit using a browser user-agent switcher, or ask us to run a diagnostic. If you see unfamiliar links, gambling pages, or redirect pages — your site has been compromised.

What We Found on Our Platform

On 21 April 2026, we ran a full automated audit across all WordPress installations hosted on our platform.

Result: zero infections. None of the 31 affected plugin slugs were present on any install. Every wp-config.php file was normal size. No injection markers detected. The backdoor file was not present anywhere on the server. Our clients were not exposed.

We have added the 31 affected slugs to our standard monthly security audit process. Any future appearance of these plugins — including nulled or cracked installs — will be flagged immediately.

The Bigger Picture: Plugin Ownership Is a Security Issue

This attack did not exploit a code vulnerability in the traditional sense. It exploited a structural gap in how WordPress manages plugin ownership. When a plugin changes hands on Flippa or any other marketplace, WordPress.org receives no notification. There is no code review triggered by a change of committer. There is no alert to existing users that the developer who wrote the code they trusted no longer controls it.

The attacker understood this. They purchased trust as a commodity, and they used it.

This attack occurred in the same week as a separate compromise of Smart Slider 3 Pro — a plugin with over 800,000 active installations — where attackers pushed a weaponised update through the official channel. Two supply chain attacks in one week, both exploiting the implicit trust that WordPress users place in the update mechanism.

Practical steps for site owners:

• Review who maintains your plugins. Check the WordPress.org page for any plugin you rely on — has the author changed recently?
• Reduce your plugin count. Every plugin is an attack surface. If you installed something and never use it, delete it.
• Avoid auto-updates for critical plugins. E-commerce, authentication, and form plugins should be manually reviewed before updating.
• Maintain working backups. A clean backup from before an infection is the fastest path to recovery.

Not Sure Whether Your Site Is Affected?

If you are a Com Technology client, you do not need to do anything — we have already checked and your site is clean.

If you manage your own WordPress site and you are not confident about any of the checks above, get in touch. We can run a security audit, check for indicators of compromise, and advise on remediation if anything is found.