Seven WordPress Plugins Were Compromised Without a Single File Changing. Here Is What to Check.

You inherited the association website from someone who left two years ago. It was built with Elementor and a stack of add-on plugins you did not choose. You have done the one thing everybody tells you to do, which is keep everything updated, and the dashboard has said everything is up to date for months.

That was the right instinct. Last week something happened that your update habit could not have prevented, and that updating now will not undo. It is worth twenty minutes of your time this week, and the checks at the end of this post are ones you can run yourself or hand to a contractor.

What Wordfence Reported

On August 7, the security firm Wordfence published findings on a supply chain compromise affecting seven plugins from BdThemes, a developer whose products have more than 350,000 active installations between them. The largest is Element Pack Addons for Elementor, with over 100,000 active installs. The others named are Prime Slider, Ultimate Post Kit, Pixel Gallery, Ultimate Store Kit, Live Copy Paste and Smart Admin Assistant.

Here is the part that makes this different from an ordinary vulnerability. According to Wordfence, attackers obtained write access to a DigitalOcean Spaces storage bucket used by the vendor to serve a promotional data feed, and replaced the legitimate JSON with crafted payloads. The plugins fetched that feed as they were designed to do.

The flaw the payload exploited was modest on its own. Wordfence rates it CVSS 5.4, a medium, and describes it as insufficient escaping of a value called display_id from the remote feed before it was written into the admin dashboard. Wordfence dates the parsing flaw to March 2026, puts the earliest possible start of the campaign at June 23, and says its firewall began seeing attacks on August 7. WordPress.org closed the affected plugins on August 7 and 8 pending review.

What happened next is why a medium-severity rating understates this. Wordfence reports that when a logged-in administrator loaded wp-admin on an affected site, the injected script used that administrator's own session to create rogue administrator accounts and install a web shell.

Why Updating Did Not Prevent This, and Does Not Fix It

No plugin file changed on any victim site. The malicious content arrived through a live data feed the plugin was built to request, which means there was no update to apply and nothing for a scanner comparing files against the official version to notice.

Now the harder half. That is worth sitting with, because it defeats the advice almost every association has been given. Keeping everything updated is genuinely good practice and we have written about why patch timing matters. It is not sufficient, and this incident is the clearest illustration of the gap in a long time.

And this is the part people are getting wrong this week. Per Wordfence's account, the rogue administrator account and the web shell exist independently of the plugin. Removing the plugin, updating it, or waiting for a fixed version does not remove them. If a site was hit, it is still compromised today, and the remedy is an audit rather than an update.

The Four Things to Check

These are the indicators Wordfence published. You do not need to be a developer to look for the first two, and a contractor can handle the rest in under an hour.

• Administrator accounts you did not create. In wp-admin under Users, sort by date registered and look at anything recent you do not recognize. Wordfence reports the rogue accounts use usernames beginning with bd_ followed by six characters, and email addresses on the @wordpress.org or @developer.wordpress.org domains. No legitimate account on your site should have a wordpress.org email address.
• Files in the mu-plugins folder. This folder sits inside wp-content and its contents load automatically without appearing in the normal plugins list, which is exactly why attackers like it. Wordfence names several files planted there, including class-wp-token-validate.php, wp-cache-optimizer.php, and files matching class-wp-query with a suffix. Anything in that folder you cannot account for deserves an explanation.
• Two specific database options. Wordfence lists two database options as indicators, fz_emer_login_tokens and fz_emer_done_v1. Checking these needs database access, so this is the item to hand to whoever maintains the site.
• A plugin nobody installed. Wordfence reports a planted plugin with a deliberately unremarkable name, observed as wp-smart-thumbnails, containing a web shell file called emer-run.php. Scan your plugin list for anything nobody remembers installing, and treat a plugin with no author, no version history, and no memory attached to it as suspect.

One caution about that first check. Wordfence also documented that the attack included a component designed to hide the rogue accounts from the user list. If you have any reason to believe your site was affected, an empty-looking Users screen is not proof of anything.

If You Find Something

Do not simply delete the account and move on. An intruder who had administrator access long enough to install a web shell had long enough to leave more than one way back in. Work through it in this order.

• Rotate the authentication keys and salts in wp-config.php. This invalidates every existing session, including the attacker's.
• Reset the passwords for every legitimate administrator.
• Remove the planted files and accounts, and look for a second payload rather than stopping at the first.
• Restore from a backup taken before June 23 if you have one and the site can tolerate it. This is the only approach that is genuinely conclusive.

One more thing, and it is the one associations forget. If your website handles member data, registrations, or payments, this is also the point to involve whoever advises your organization on disclosure obligations. That is a conversation to start early rather than after you have finished cleaning up.

The Other Release You Probably Missed

Separately, WordPress shipped 7.0.3 on August 6 with a fix for a pre-authentication cross-site scripting flaw on the login screen, CVE-2026-64638, reported by the pwn.ai research team and rated CVSS 8.9. That one is an ordinary patch and applying it does resolve it. Fixes were backported through the 4.7 branch, so even a long-neglected site is covered by updating. Anything older than 4.7 is not.

Note the difference between the two. Two events, forty-eight hours apart, and only one of them is solved by pressing Update. That contrast is the actual lesson of this week.

What This Should Change

Not your update policy. Keep updating, promptly, especially for security releases. What this should change is the belief that updating is the whole of the job.

The broader point is about what a plugin actually is. Every plugin that fetches remote data is a piece of somebody else's infrastructure running inside your admin dashboard. That is not an argument against plugins, which would be unrealistic advice for any association. It is an argument for knowing what your site runs, who maintains each piece, and having somebody who reads security advisories in the days when nothing appears to be wrong.

Most Sites Are Fine

If your association does not use Elementor, or uses it without BdThemes add-ons, this specific campaign does not touch you. And even among affected sites, exposure required an administrator to load wp-admin during the window. This is worth checking, not worth panicking about, and we would rather say so than manufacture urgency.

Check your plugin list for the seven names above. If none of them are there, you are done, and it took five minutes.

Where to Start

Open your Users page and your plugin list today. Those two checks cost nothing and rule out the majority of the risk. If you find something, or if you cannot tell, that is exactly the moment to bring in somebody who does this work rather than experimenting on a live site.