SURIQ
The plugin files were never touched. That is the part every WordPress operator needs to sit with, because it breaks the mental model most people use to reason about supply-chain risk. According to Wordfence, the attackers behind the BdThemes compromise never modified a single line of code in the plugins hosted on WordPress.org. The malicious code arrived later, at runtime, inside a data feed the plugin fetched and trusted. Your checksum matched. Your version was current. The site still got a hidden administrator and a webshell.
BdThemes is a busy WordPress plugin vendor whose products, including Element Pack, Prime Slider, and Ultimate Post Kit, run on hundreds of thousands of sites. On August 8, 2026, the WordPress.org plugins team pulled seven of its plugins from distribution after Wordfence reported an active supply-chain attack. This is the mechanism, why the usual defenses missed it, and what a site owner has to do now, because deleting the plugin is not it.
A poisoned data feed, not a poisoned plugin
BdThemes plugins bundle a shared helper, the Biggop library, and one of its components pulls a small promotional banner for the admin dashboard from a remote server the vendor controls. Researchers reported that the attackers gained write access to that upstream storage and changed the JSON the banner component fetched. A cross-site scripting flaw in how that component handled the feed, rated 5.4 by the researchers who found it, meant the poisoned JSON was parsed and run as JavaScript inside the logged-in administrator's browser.
From there the injected script did what a real admin can do, because it was riding a real admin's session. Wordfence describes it contacting an external server for instructions, then using the site's own REST API to create new administrator accounts. It installed a fake plugin carrying a PHP webshell, and it dropped two files into the must-use plugins directory: one that grants unauthenticated admin access through a URL parameter, and one that rewrites database queries so the rogue accounts never appear in the user list. One variant generated its admin credentials deterministically, so the operator could log back in later without storing anything.
The flaw was introduced around March 1, 2026, and sat dormant for months. Wordfence places the earliest attack activity around June 23 and detected the campaign on August 7. So this was a medium-severity bug, the kind that slides down most triage queues, that turned into full site takeover the moment someone with write access to the vendor's feed decided to use it. The poisoned endpoints now return clean data, but the sites hit during that window are still compromised.
Why every integrity check passed clean
Most supply-chain defense for WordPress is built around one question: is this plugin the genuine, unmodified version the author published? Checksums, the "reinstall from the official repository" button, package scanners that diff your files against WordPress.org, all of them answer that question. Here they all answer "yes," correctly, and it does not help. The payload never lived in the package. It lived in a data stream the package went and fetched after installation, from infrastructure outside WordPress.org's control.
That is the structural lesson, and it is bigger than one vendor. Any plugin that phones home for content, banners, license checks, update manifests, or telemetry is trusting a second server that your integrity tooling does not inspect. We saw the same shape when a hijacked ad-tracking script swapped crypto wallet addresses in visitors' browsers: the served file changed, the origin did not. Integrity of the artifact is not integrity of everything the artifact does at runtime.
Deleting the plugin does not clean the site
This is the part the wire coverage skips, and it is the part that matters most operationally. The webshell and the two must-use plugin files run independently of BdThemes. Remove or update every BdThemes plugin and those files stay exactly where they are, still granting access, still hiding the accounts. A team that reads "plugins pulled from the repository," updates, and moves on has done nothing to the attacker's foothold.
Worse, the account-hiding module means your first instinct, opening Users in the dashboard to look for something odd, returns a clean list by design. The rogue admins are filtered out of the exact screen you would check. If you were running an affected BdThemes plugin at any point since late June, treat the site as compromised until proven otherwise, not the reverse.
How to tell if you were hit
Because the dashboard lies to you here, detection has to happen below it:
-
Query the users table directly. Count administrators against the wp_users and wp_usermeta tables in the database, not the admin screen, and compare that number to the accounts you recognize.
-
Inspect the must-use plugins directory. List every file in
wp-content/mu-plugins. These load automatically and cannot be disabled from the dashboard, which is exactly why attackers use them for persistence. Anything you did not put there is suspect. -
Watch for the drop, not just the account. A new PHP file appearing under
wp-content/pluginsormu-plugins, and a REST call that creates a user, are the two events to alert on. File integrity monitoring on those directories catches the persistence even when the account itself is hidden from you. -
Review outbound connections from the site. The injected script calls out to an external host for instructions. Unexpected outbound requests originating from admin page loads are the tell.
The admin browser is the execution environment now
Step back and this is the third WordPress incident in recent months to weaponize a logged-in administrator's own session instead of an unauthenticated request. Awesome Motive's CDN backdoor only fired for logged-in admins, which is how it slipped past scanners looking at anonymous traffic. The AI Engine plugin flaw turned a link an admin clicked into a rogue admin account. The common thread is that the defense most sites lean on, a web application firewall filtering hostile requests from strangers, never sees code that runs as the administrator inside the dashboard. When the trusted browser is the attack surface, request filtering is looking the wrong way.
According to Wordfence, the campaign's command-and-control infrastructure overlaps with infrastructure tied to earlier reported plugin compromises, including ones affecting OptinMonster and Advanced Responsive Video Embedder, which suggests one operation working methodically through vendors whose plugins reach into the admin panel. Expect more of it. The plugins that are most useful in the dashboard are the ones with the most reach when their trust is turned against you.
Rebuild the foothold out, then rotate
If an affected plugin was ever on your site, the response is not an update, it is an eviction. Remove the webshell and any unfamiliar files in wp-content/mu-plugins and wp-content/plugins. Find and delete the hidden administrator accounts at the database level. Rotate every credential that a resident attacker could have read: admin passwords, application passwords, API keys, and database credentials. Only once the foothold is gone does reinstalling a clean plugin, or replacing it, make sense. The webshell-on-CMS pattern is well worn; the difference this time is that a current, "genuine" plugin was the delivery route, so trusting the version number is what got sites here in the first place.