Seven WordPress plugins were compromised without touching a line of their code

Wordfence researcher Paolo Tresso reported a supply chain compromise affecting seven BdThemes plugins, and the mechanism is the reason it matters.

Threat actors poisoned a static remote JSON data stream fetched by an administrative promotional banner component.

Read that again with a code reviewer's eye. Nothing in the plugin source was modified. Anyone auditing the repository, diffing releases, or checking checksums would have found exactly what they expected.

The affected plugins

How it worked

The Biggopti component carries a cross-site scripting flaw and fetches promotional JSON files from a DigitalOcean Spaces bucket. Attackers compromised the bucket credentials and injected payloads there.

The XSS itself is rated CVSS 5.4 — medium. That rating describes the flaw. It does not describe what happened, because the flaw was only the delivery mechanism for content the attacker fully controlled.

The injected JavaScript, w2.js, ran silently on every admin page load and:

• created rogue administrator accounts through the WordPress REST API
• downloaded fake plugin ZIPs containing PHP web shells
• established persistence via backdoors in the Must-Use plugins directory

The Must-Use directory is the choice that shows intent. Plugins there load automatically, cannot be deactivated from the dashboard, and are not listed in the normal plugin screen. Removing the compromised plugins does not remove that.

Timeline

Five months between introduction and takedown.

The command-and-control infrastructure connects to earlier supply chain attacks involving Advanced Responsive Video Embedder and OptinMonster — the same operator, working the same ecosystem.

Why this defeats the usual checks

The WordPress plugin security model assumes the code is the artefact. Reviews look at code. Version pinning pins code. Integrity checking hashes code.

This attack changed data the code fetches at runtime, from infrastructure the plugin vendor owns but that no reviewer inspects. The trust boundary moved from "the plugin repository" to "whoever holds the vendor's object storage credentials", and nothing in the ecosystem tracks the second one.

It is the same structural gap behind the npm dropper that pushed 846 malicious packages and behind dangling DNS records that let subdomains be taken over — the dependency you actually have is not the one in your lockfile. It is every endpoint your dependency talks to.

If you run any of these

Removing or updating the plugin is not sufficient. The payload's job was to survive that.

• Audit administrator accounts. Look for accounts created since March 2026 that nobody recognises. Check the REST API log if you keep one.
• Inspect wp-content/mu-plugins/. Anything there that you did not put there is a backdoor, not a feature.
• Look for unexpected plugin ZIPs and PHP files with recent timestamps outside normal update windows.
• Rotate everything the site holds — admin passwords, API keys, database credentials, payment integrations.
• Assume compromise if the plugin was active on an admin session at any point since March. The payload ran on page load, not on user action.

The broader point for plugin authors

A promotional banner that fetches remote JSON is a feature nobody asked for, running with admin-page privileges, on every load, forever.

The cost-benefit here is not close. The feature exists to advertise the vendor's other products. The risk it carries is full site compromise for 100,000+ installations. That trade was made once, in a commit, and was never revisited.

If you ship a plugin: any remote fetch that renders in an admin context is a permanent liability against whatever infrastructure serves it. Object storage credentials leak. That is a thing that happens.