The pattern documented in anchor.host's writeup is uncomfortably tidy: pick small WordPress plugins whose original author is no longer interested, buy the listing, ship a "fixes and improvements" release a few weeks later, and watch a few hundred thousand sites auto-update themselves into a backdoor.

Why this works

  • Trust transfers with the listing. The plugin keeps its slug, its star rating, its install base, and its update channel. Site owners see "an update is available" and click. No friction, no review.
  • The malicious change can be tiny. Adding a single inline <script src> to one admin page, or one curl-based check-in to a remote endpoint, is enough. It doesn't have to look like malware. Sometimes it doesn't even do anything yet — it just calls home for instructions later.
  • The blast radius is the install base. A plugin with 50,000 installs reaches 50,000 sites with a single push. If the buyer collects 30 plugins, that's a million sites of potential reach.

How to tell

You can't always tell from the plugin listing whether the maintainer has changed. Some things that help:

  • Watch for ownership changes. WordPress.org doesn't surface this prominently, but a sudden change in the author's other plugins, a fresh Contributors line, or a stale changelog that suddenly resumes after years can be signals.
  • Diff the release. wp plugin download followed by diff -r against the previous version of the plugin folder tells you exactly what changed. Most updates touch a small surface; a fresh-from-acquisition release that touches class-loader.php AND adds a new wp-cli command AND modifies admin-ajax.php is worth a closer look.
  • Network egress. A plugin that did not previously make outbound requests but suddenly starts hitting a domain you don't recognise is the smell. Sandbox a fresh install and watch DNS.

What to do on the sites you already run

  • Inventory. A list of every plugin on every site you own, with last-updated dates and active install counts. The site that has eight plugins you haven't touched in three years is the one with the latent risk.
  • Cull. Anything you're not actively using, remove from disk (not just deactivate).
  • Pin if you can't update. For sites where the auto-update channel is the risk you're trying to avoid, disable auto-update for plugins specifically and review every update before you ship it. define('AUTOMATIC_UPDATER_DISABLED', false) keeps core updates on while you take control of plugin updates manually.

If you suspect a site you operate caught an update like this, the cleanup is roughly the same as any backdoor: identify the entry vector, find every persistence mechanism, rotate every secret, and audit the database. The harder part is the inventory question — what other plugins on that same site are also vulnerable, just for the same structural reason.

Source: anchor.host — Someone bought 30 WordPress plugins and planted a backdoor in all of them.