Every WordPress security habit most marketing teams have is built on one assumption: that a compromise involves a file changing. Scan the files, compare them against the repository, keep everything updated, and you will see it. Last week that assumption stopped working.
Seven BdThemes plugins were used to create hidden administrator accounts and install webshells on live sites. No plugin file was modified. No update was required. The plugin code in the WordPress.org repository was, and remained, exactly what it was supposed to be.
What actually happened
BdThemes plugins include a component that pulls promotional banners from a remote API and displays them inside the WordPress admin dashboard. An attacker compromised that upstream feed and changed what it returned. The plugin then did what it was built to do: fetch the content and render it in wp-admin.
The underlying flaw is a cross-site scripting issue rated 5.4, medium severity, apparently introduced in Prime Slider 4.1.9 on 1 March 2026 before spreading to other products in the range. On its own, a medium-severity XSS in an admin banner is the kind of finding that sits in a backlog for months. Combined with control of the feed it renders, it became an admin takeover.
The payload runs in the logged-in administrator’s own browser session. It creates a new administrator account, either through the REST API or the standard user creation flow, then downloads and installs a plugin with a plausible name, one reported example being wp-smart-thumbnails, containing a webshell for persistent access. Everything happens with your credentials, from your browser, on a site where nothing on disk looks unusual.
Wordfence was notified on 7 August. The earliest possible start of the campaign is 23 June, which is the number that should worry you, because it means “I checked last week and it was fine” covers roughly the last six weeks of a seven week window.
The affected plugins are Element Pack Addons for Elementor, Prime Slider Addons for Elementor, Pixel Gallery Addons for Elementor, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste and Smart Admin Assistant. They were pulled from the repository while the WordPress Plugins team investigates.
The twenty minute check
If any of those plugins have been on your site since June, do this today rather than this week. If you are not sure, check anyway, because Elementor add-on packs are exactly the kind of thing a previous agency installs and nobody remembers.
- Users, then Administrator. Count them. You should be able to name every single one out loud. Any account you cannot immediately account for is the finding, regardless of how ordinary the username looks.
- Sort users by registration date. Anything created since 23 June that you did not create yourself gets investigated before anything else.
- Plugins list. Look for anything installed that nobody on your team installed, particularly names that sound like generic utilities. Check the plugin’s page on WordPress.org actually exists.
- Application Passwords. Open each admin profile and look at the bottom. Any application password you did not create is a live credential that survives a password reset.
- Users again, after cleanup. Removing a rogue admin without removing its application passwords and its webshell plugin achieves nothing.
If you find something, assume the site is compromised rather than assume you caught it early. That means restoring from a backup predating 23 June if you have one, or bringing in someone who does incident response for a living. A marketing team cleaning up a webshell by deleting the file it can see is the most common way sites get reinfected a fortnight later.
The separate thing you also need to patch
Running alongside this, and unrelated to it, WordPress shipped an emergency fix on 6 August for a flaw researchers named XSS2Shell, tracked as CVE-2026-64638 and rated 8.9. It starts as an unauthenticated cross-site scripting bug on the login screen, caused by two of WordPress’s own sanitisation routines disagreeing about what counts as a tag, and chains through to PHP execution on the server. The chain needs a logged-in administrator to click something on an attacker-controlled page, which in the researchers’ demonstration is a single ordinary click.
The fix is WordPress 7.0.3. There is no confirmed exploitation in the wild yet. If your site auto-updates core, you are probably already on it, and it takes ten seconds to confirm.
The habit that actually protects you
Here is the uncomfortable part. Updating everything on schedule would not have prevented the BdThemes compromise. The plugins were legitimate, current, and correctly signed. The malicious content arrived over the network at runtime, into the one part of your site you assume is safe because you are the only one who sees it.
Which means the control most teams treat as their security posture, keeping plugins updated, was never the control they thought it was. It is necessary and it is not sufficient. The thing that would have caught this in a day is much less impressive: knowing exactly how many administrator accounts your site is supposed to have, and looking at that list on a fixed schedule.
Make it monthly, put it in a calendar, and write the expected admin count somewhere you will see it. A site with three admins and a written note saying “three admins: Sarah, Tom, the developer” catches a fourth in about four seconds. A site where nobody knows the expected number will not catch it at all.
What to avoid
Do not respond to this by ripping out every Elementor add-on you have. Plugin count is a real risk factor, but panic-removing page builder dependencies on a live commercial site tends to break layouts on pages that make money, and the tradeoff rarely favours the person doing it at 6pm.
Do not assume a managed host has handled it. Host-level scanning looks for modified files and known malware signatures. A legitimate plugin rendering a poisoned banner, and a user account created through the official REST API, look like normal site activity from the outside.
And be careful about the opposite error. If you run a small brochure site with two plugins and one admin, this is a ten minute check and then you are done. Not every security story requires a project.
The reporting on the mechanism, including the payload behaviour, is set out in the BdThemes supply chain analysis, and the login screen flaw is documented in this WordPress pre-auth XSS write-up. We covered a more conventional version of this problem last week in the WooCommerce login plugin that handed out admin access, where updating was the fix. This time it was not.
Go and count your administrators.
Editor’s note: This is an active investigation and details may change, so check the latest vendor advisories before making decisions about your site.