122995

The backdoor wasn’t a smash-and-grab. It wasn’t noisy, and it wasn’t rushed. It was planted quietly and left to sit for eight months before anyone flipped the switch.

I traced the plugin’s history through 939 quicksave snapshots. The code tells a very specific story if you’re willing to read it line by line.

The plugin had been on the site since January 2019. The wpos-analytics module was always there, functioning as a legitimate analytics opt-in system for years. Nothing unusual. Nothing suspicious. Just another piece of boilerplate tracking code bundled into a widely used plugin.

Then came version 2.6.7, released August 8, 2025.

The changelog said:
“Check compatibility with WordPress version 6.8.2.”

What it actually did was add 191 lines of code, including a PHP deserialization backdoor. The class-anylc-admin.php file grew from 473 lines to 664.

Buried in that diff were three critical additions:

  • A fetch_ver_info() method that calls file_get_contents() on a remote server and feeds the response directly into @unserialize()
  • A version_info_clean() method that executes @$clean($this->version_cache, $this->changelog) where every variable originates from attacker-controlled serialized data
  • An unauthenticated REST API endpoint with permission_callback: __return_true

That is a textbook arbitrary function call vulnerability. The attacker controls the function name, the arguments, and the execution flow. It’s full remote code execution, disguised as version metadata handling.

And then… nothing.

No activity. No payload. No exploitation.

For eight months.

Until April 5–6, 2026.

That’s when analytics.essentialplugin.com began serving malicious payloads to every site running these plugins. The dormant backdoor woke up simultaneously across hundreds of thousands of installations.

This wasn’t an opportunistic exploit. It was premeditated infrastructure.

The acquisition

The plugin wasn’t originally malicious. That’s what makes this case more concerning.

It was built by an India-based team—Minesh Shah, Anoop Ranawat, and Pratik Jain—operating under “WP Online Support” starting around 2015. Over time, they built a portfolio of more than 30 free plugins, many with paid upgrades. In 2021, they rebranded to “Essential Plugin.”

By late 2024, revenue had dropped between 35% and 45%. The business was listed for sale.

A buyer identified only as “Kris,” with a background in SEO, crypto, and online gambling marketing, acquired the entire portfolio in early 2025 for six figures through Flippa. The transaction wasn’t hidden. It was public. It was even featured as a success story.

Two days after the original developers’ final commits in May 2025, the ownership transition was complete. Author headers were changed. A new WordPress.org account appeared.

Then, on August 8, 2025, the first commit from the new owner landed.

It contained the backdoor.

The very first commit.

Timeline of a supply chain compromise

  • February 2015 — Domain registered, plugin development begins
  • October 2016 — First major plugin published
  • August 2021 — Rebrand to Essential Plugin
  • Late 2024 — Revenue decline, business listed for sale
  • Early 2025 — Acquisition completed by “Kris”
  • May 2025 — Original developers exit, new account takes over
  • August 8, 2025 — Version 2.6.7 introduces backdoor under false changelog
  • August 30, 2025 — WHOIS updated to a Zurich-based identity using ProtonMail
  • April 5–6, 2026 — Backdoor activated, payload distribution begins
  • April 7, 2026 — All plugins from the author closed in a single day
  • April 8, 2026 — Forced patch pushed to all installations

Eight months from insertion to activation. No accidental discovery. No early trigger. Just patience.

The mass shutdown

On April 7, 2026, the WordPress.org Plugins Team took the nuclear option.

Every plugin from the Essential Plugin author account was permanently closed. More than 30 plugins disappeared in a single day. The author page now returns nothing. The distribution endpoint returns a simple message: {"message":"closed"}.

Among the affected plugins were widely used tools for sliders, galleries, WooCommerce displays, testimonials, and post grids—components embedded deep into production websites.

Here’s a list with some of the compromised wordpress plugins:

  • 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

This wasn’t a niche package. It was infrastructure.

The coordinated shutdown strongly suggests a shared code pattern across all plugins. And that pattern centers on the wpos-analytics module.

The payload vector

The attack chain is simple but effective:

  1. Ship benign analytics module for years
  2. Introduce backdoor via trusted update
  3. Wait for adoption across installed base
  4. Activate remote payload delivery simultaneously

The use of unserialize() on remote data is the critical piece. It allows object injection, which in turn enables arbitrary method calls depending on available classes. Combined with the $clean function call, it becomes a flexible execution primitive.

Because the endpoint required no authentication, any external trigger could initiate the chain.

This is not just a vulnerability—it’s a remotely controlled execution framework embedded in legitimate plugins.

This has happened before

If this feels familiar, it should.

In 2017, a buyer using the alias “Daley Tias” purchased the Display Widgets plugin, which had over 200,000 active installs, for $15,000. Within weeks, it was injecting payday loan spam. That same actor went on to compromise multiple plugins using identical tactics.

The Essential Plugin case follows the same playbook—just at a larger scale.

More plugins. More installs. More patience.

Patching and remediation

If you still have one of these plugins and haven’t received or trusted the forced update, the remediation path is straightforward:

  • Delete the wpos-analytics/ directory entirely
  • Remove the analytics loader block in the main plugin file (look for markers like “Plugin Wpos Analytics Data Starts” or wpos_analytics_anl)
  • Bump the version string (e.g., append -patched)
  • Repackage and reinstall the plugin

But plugin cleanup is only part of the story.

Check your wp-config.php.

The malware appends itself onto the same line as:
require_once ABSPATH . 'wp-settings.php';

Because it doesn’t add a new line, it’s easy to miss. If your config file is larger than expected—roughly 6KB more—you’re likely dealing with an active compromise. At that point, plugin removal isn’t enough. You need a full incident response.

The real problem: Trust

This wasn’t a zero-day exploit. It wasn’t a clever bypass of hardened defenses.

It was a business transaction.

A legitimate developer built trust over eight years. That trust was sold. The new owner inherited distribution rights and pushed malicious code through the same channel users had relied on for years.

There is no mechanism in the WordPress plugin ecosystem to flag a change of ownership. No alert to users. No mandatory review when commit access changes hands.

The acquisition was public. The buyer’s background was public. The risk signals were visible.

And nothing in the system reacted.

The Plugins Team acted quickly once the attack was discovered. But the critical window—the eight months between insertion and activation—passed without detection.

That’s the gap attackers are now targeting.

What to do now

If you manage WordPress infrastructure:

  • Audit your plugins against the affected list
  • Remove or patch anything from the Essential Plugin portfolio
  • Inspect wp-config.php for inline injections
  • Assume compromise if the backdoor was active and investigate accordingly

This wasn’t just an isolated incident. It’s a repeatable model.

Image source: Freepik