Seven popular BdThemes plugins, most of them Elementor add-ons, were pulled from WordPress.org on 7 and 8 August 2026 after researchers found they could be used to create rogue administrator accounts on any site running them. The place where the attack happened is what makes it worth reading closely: not inside the plugin code, and not inside the WordPress.org repository.
The compromise was a cloud storage bucket
According to Wordfence researcher Paolo Tresso, cited by The Hacker News, the attackers compromised BdThemes' own cloud storage, a DigitalOcean Spaces bucket used by a promotional-banner component the plugins call "Biggopti". The plugin source in the WordPress.org repository was not modified at any point. Tresso is quoted directly: "zero source code files were modified within the official WordPress.org repository."
Seven plugins, one shared component
| Element Pack Addons for Elementor | 100,000+ installs |
|---|---|
| Live Copy Paste for Elementor | 6,000+ installs |
| Pixel Gallery Addons for Elementor | |
| Prime Slider Addons for Elementor | Vulnerable code path traced back to at least 1 March 2026 |
| Smart Admin Assistant | |
| Ultimate Post Kit Addons for Elementor | |
| Ultimate Store Kit | 6,000+ installs |
How a banner became a site takeover
Biggopti fetched banner content as JSON from the compromised bucket. A cross-site-scripting flaw in how that JSON was parsed let attacker-controlled script run in the browser of any logged-in administrator, on every wp-admin page load. From there the payload created administrator accounts, installed web shells and set up persistence. Nothing on the server had to be altered for the attack to start; an administrator only had to be logged in with the plugin active.
Why "the repository was untouched" is the point
Most plugin security advice assumes a clean changelog and an unmodified codebase mean a plugin is safe. This incident shows the gap: a plugin can pull content from an external service at runtime, and that service sits outside the review WordPress.org applies to the code. The plugin's file integrity was never in question. The vendor's infrastructure was.
What to check on your own sites
- List every active plugin that pulls content from an external service at runtime: promotional banners, licence checks, remote configuration, update feeds from anywhere other than WordPress.org. That list is an attack surface separate from code quality.
- Sites running any of the seven plugins: update to the patched version, then review administrator accounts for anything you did not create.
- Keep the difference of every update. When a plugin update is the problem, the record of what it changed, on which sites, is how you find out.
The pattern is the same as the file-upload flaws in Elementor Pro and Forminator: a plugin doing something a form field or an external fetch is expected to do, without validating it the way it should.
How to find the plugins on your sites that phone home
A plugin that loads content from its vendor at runtime is not a bad plugin. Licence checks, update feeds and promotional banners are common. The point is to know which ones do, so that a vendor incident is a known exposure and not a surprise.
- Watch the network while wp-admin loads. Open the browser's developer tools on the plugins page and the dashboard, and note every request to a domain that is not your own site or wordpress.org. Each one belongs to a plugin.
- Search the plugin code for outgoing requests. In the plugin folder, look for the WordPress functions that fetch remote content and read where the addresses point. A vendor's own storage bucket or CDN is exactly the kind of address this incident was about.
- Prefer plugins whose dashboard notices can be switched off. A promotional banner is content from outside your site, rendered inside the most privileged page you have. Less of it is better.
A short policy that would have caught this
- Every plugin update waits for a person and takes a restore point first. This incident did not come through an update, but the cleanup did, and the restore point is what made it safe.
- New administrator accounts are checked on every site, several times a day, and an account nobody on the team created is a finding on its own.
- Plugins with fewer than a few thousand installs and a runtime dependency on the vendor are reviewed before they go on a client site, not after.
- The list of active plugins per site is kept somewhere you can search across all sites. When the next advisory names seven plugins, "which of our forty sites run them" should take a minute, not a Sunday.
Sources
- The Hacker News, "BdThemes Supply Chain Attack Poisons JSON to Create Rogue WordPress Admins", citing Wordfence researcher Paolo Tressothehackernews.com, August 2026