How a Flippa Purchase Turned 30+ “Essential Plugin” WordPress Plugins into Backdoor Bait

WordPress bug logo on screen with wp-config.php showing suspicious appended code

Last week I encountered a supply-chain incident that felt eerily familiar but much larger in scale. A client’s dashboard had started showing a warning from the WordPress.org Plugins Team about a plugin serving code that could permit unauthorized access. A deeper dive revealed an attacker had quietly weaponized an entire portfolio of plugins—planting a backdoor that lay dormant for months before being activated to serve cloaked SEO spam and redirects.

What the alert revealed

A notification about Countdown Timer Ultimate led to a full forensic sweep. Although WordPress.org forced an update that neutralized the plugin’s phone‑home mechanism, the real problem lived elsewhere: the attacker had managed to inject a sophisticated payload directly into wp-config.php. The plugin’s wpos-analytics module had contacted analytics.essentialplugin.com, downloaded a malicious file named wp-comments-posts.php (masquerading as a core file), and used it to append a block of PHP into wp-config.php.

That injected code didn’t just drop spam links. It fetched redirect instructions, spam pages and cloaked content from a command-and-control (C2) server and served that spam only to Googlebot, making detection by site owners much harder. Even more unusual: the malware resolved its C2 domain via an Ethereum smart contract, querying blockchain RPC endpoints so the attacker could change the active domain without relying on traditional DNS. Typical takedown tactics would have limited effect.

Forensics: finding the injection window

Thanks to daily backups, I could binary-search the wp-config.php snapshots to pinpoint when the injection happened. The file size remained steady across several months and then jumped significantly during a narrow window:

Date File size (bytes)
Nov 1, 2025 3,346
Jan 1, 2026 3,346
Mar 1, 2026 3,345
Apr 1, 2026 3,345
Apr 5, 2026 3,345
Apr 6, 04:22 UTC 3,345
Apr 7, 04:21 UTC 9,540

The injection occurred between Apr 6, 04:22 UTC and Apr 7, 04:21 UTC—an interval of approximately 6 hours and 44 minutes. What’s worse: the malicious code had been committed to the plugin codebase eight months earlier but remained dormant until early April.

How the backdoor was introduced

Tracing plugin history revealed the culprit code landed in a release published on August 8, 2025 (version 2.6.7). The change log deceptively claimed a compatibility update for WordPress 6.8.2, but the commit added 191 lines to the analytics module and introduced a PHP deserialization backdoor. Key elements included:

  • A fetch_ver_info() method that called file_get_contents() on a remote server and passed the response to @unserialize().
  • A version_info_clean() method that executed @$clean($this->version_cache, $this->changelog) where the function name and arguments came directly from the unserialized remote payload.
  • An unauthenticated REST API endpoint whose permission_callback returned true, allowing arbitrary remote data to trigger the vulnerable code path.

Together these allowed the remote server to control which function to call and what arguments to pass—essentially arbitrary remote code execution. The code sat unused for months until weaponized in April.

The acquisition that changed everything

The plugin family originated with a team operating as WP Online Support (later Essential Plugin). Over several years they built a portfolio of more than 30 free plugins, many with premium add-ons. By late 2024 revenue had declined and the owner listed the entire business for sale on Flippa. A buyer (identified only as “Kris” in public records) with a background in SEO, crypto and gambling marketing acquired the portfolio for a six-figure sum. Shortly after the ownership change the repository authorship changed and commits from the new account began introducing the backdoor code.

Timeline (high-level)

  • 2015–2021: WP Online Support / Essential Plugin builds a portfolio of plugins.
  • Late 2024: Revenue declines; business listed on Flippa.
  • Early 2025: Buyer acquires Essential Plugin portfolio via Flippa.
  • May–August 2025: New commits appear under the new owner; backdoor code is committed in August 2025 (v2.6.7).
  • April 5–7, 2026: Backdoor is activated and starts distributing payloads.
  • April 7–8, 2026: WordPress.org closes the author’s plugins and forces an update to neutralize phone-home logic.

Scale and scope of the takedown

On April 7, 2026 the WordPress.org Plugins Team closed every plugin published by the Essential Plugin account—at least 30 plugins removed in a single day. WordPress.org now returns no results for that author and analytics.essentialplugin.com shows a “closed” message. The forced update that followed was useful to halt further phone-home calls, but it did not strip the injected code from site wp-config.php files, nor did it fully remove the analytics module from installed plugin files. In short: a partial remediation, not a comprehensive cleanup.

Plugins confirmed closed (table)

Plugin Slug
Accordion and Accordion Slider accordion-and-accordion-slider
Album and Image Gallery Plus Lightbox album-and-image-gallery-plus-lightbox
Audio Player with Playlist Ultimate audio-player-with-playlist-ultimate
Blog Designer for Post and Widget blog-designer-for-post-and-widget
Countdown Timer Ultimate countdown-timer-ultimate
Featured Post Creative featured-post-creative
Footer Mega Grid Columns footer-mega-grid-columns
Hero Banner Ultimate hero-banner-ultimate
HTML5 VideoGallery Plus Player html5-videogallery-plus-player
Meta Slider and Carousel with Lightbox meta-slider-and-carousel-with-lightbox
Popup Anything on Click popup-anything-on-click
Portfolio and Projects portfolio-and-projects
Post Category Image with Grid and Slider post-category-image-with-grid-and-slider
Post Grid and Filter Ultimate post-grid-and-filter-ultimate
Preloader for Website preloader-for-website
Product Categories Designs for WooCommerce product-categories-designs-for-woocommerce
Responsive WP FAQ with Category sp-faq
SlidersPack – All in One Image Sliders sliderspack-all-in-one-image-sliders
SP News And Widget sp-news-and-widget
Styles for WP PageNavi – Addon styles-for-wp-pagenavi-addon
Ticker Ultimate ticker-ultimate
Timeline and History Slider timeline-and-history-slider
Woo Product Slider and Carousel with Category woo-product-slider-and-carousel-with-category
WP Blog and Widgets wp-blog-and-widgets
WP Featured Content and Slider wp-featured-content-and-slider
WP Logo Showcase Responsive Slider and Carousel wp-logo-showcase-responsive-slider-slider
WP Responsive Recent Post Slider wp-responsive-recent-post-slider
WP Slick Slider and Image Carousel wp-slick-slider-and-image-carousel
WP Team Showcase and Slider wp-team-showcase-and-slider
WP Testimonial with Widget wp-testimonial-with-widget
WP Trending Post Slider and Widget wp-trending-post-slider-and-widget

What I did and what site owners should do

I patched affected plugins in my fleet by removing the entire wpos-analytics module, deleting the loader function inside the main plugin file, and bumping the version to a -patched release. Those patched builds were hosted to make recovery faster for my clients. But patching the plugin alone is insufficient if the site’s wp-config.php was modified: the injected payload often appends itself to the same line as the require_once ABSPATH . wp-settings.php; statement, and the extra code can be missed on a quick inspection. The injected block is roughly 6KB, so any unexpectedly large wp-config.php is a red flag that demands a full cleanup.

If you find any of the affected plugin slugs on your sites:

  • Remove or replace the plugin immediately if you cannot verify its integrity.
  • Search wp-config.php for appended code on the same line as require_once ABSPATH . wp-settings.php; and compare file sizes to backups.
  • If wp-config.php is inflated or contains foreign code, assume full compromise and perform a comprehensive cleanup (clean backups, rotate secrets, reissue keys, check for other persistence mechanisms).

Why this keeps happening—and what WordPress.org lacks

This incident follows a familiar playbook: acquire a trusted plugin with a sizable install base via a public marketplace, obtain WordPress.org commit access, and introduce a backdoor. A similar campaign occurred in 2017 when a buyer purchased Display Widgets and injected payday loan spam. The underlying problem is structural: WordPress.org doesn’t currently enforce any mandatory scrutiny or notification when plugin ownership changes hands. There’s no automated “change-of-control” flag that triggers extra review or forces an owner-initiated security audit, leaving users exposed to malicious intent hidden behind legitimate version bumps.

Final takeaways

  • Treat plugin ownership changes as a high-risk event. Verify any significant author or commit changes and audit code after an ownership transfer.
  • Don’t assume forced updates or plugin removals fully remediate infections—check core files, especially wp-config.php, for injected payloads.
  • Monitor backups and incorporate file-size comparison checks into your incident response playbook to detect stealthy injections.
  • If you manage many WordPress sites, proactively search for the plugin slugs listed above and apply patches or remove the plugins immediately.

The Plugins Team moved quickly once the attack was discovered, but the eight-month window between backdoor insertion and detection illustrates how supply-chain attacks can stealthily erode trust. If you use any plugin from this portfolio, treat it like a breach indicator and act now.

Source: https://anchor.host/someone-bought-30-wordpress-plugins-and-planted-a-backdoor-in-all-of-them/

Leave a Reply

Your email address will not be published. Required fields are marked *