BdThemes Plugins: Supply-Chain Attack Creates Hidden WP Admins

Published on 13 August 2026

Your WordPress website may have been compromised without a single file on your server being altered. That is precisely what makes the supply-chain attack on popular BdThemes plugins, uncovered by the Wordfence security team in early August 2026, so alarming. The attackers didn't manipulate the plugin itself, but rather an external data source from which the plugin regularly loads advertising banners. The result: covert administrator accounts, hidden PHP backdoors and persistent backdoors – triggered simply by a logged-in administrator opening their site's admin interface.

The free plugin Element Pack Addons for Elementor alone has more than 100,000 active installations, according to BleepingComputer. A total of seven BdThemes plugin packages are affected. If you use one of them, you should read this article to the end – because this is not an ordinary update matter, but potentially a security incident that requires forensic examination.

What happened?

The affected BdThemes plugins contain a component called Biggopti. Every time the WordPress admin area (wp-admin) is opened, this component loads banner data from an external source – specifically from a cloud storage (DigitalOcean Spaces, secured via Cloudflare). This data arrives as a so-called JSON file, a structured text format for exchanging data between programs.

The attackers gained write access to this upstream data source and "poisoned" it. To do so, they did not need to inject a manipulated plugin into the official WordPress.org repository – a crucial difference from classic supply-chain attacks. Paolo Tresso of Wordfence describes it like this:

"Unlike traditional software supply chain attacks, not a single source-code file was altered in the official WordPress.org repository. Instead, the attackers poisoned a static remote JSON data stream that is fetched by an administrative advertising-banner component." (Source: The Hacker News)

The problem in detail: A value called display_id from this JSON file was inserted directly into the HTML code of the admin page – without adequate sanitisation (known in technical jargon as "escaping", which neutralises dangerous characters). This allowed the attackers to inject malicious JavaScript into the browser session of a logged-in administrator via a crafted string. This is called cross-site scripting (XSS) – the unauthorised execution of foreign script code in the context of a website.

The insidious part: The malicious script ran automatically on every access to wp-admin – and did so with the full privileges of the logged-in administrator.

Why this is more dangerous than the severity rating suggests

Wordfence rates the underlying technical flaw as "medium" with a CVSS score of 5.4. But this score only reflects the XSS vulnerability itself, not the actual damage of the campaign. Because what the attackers achieved with the script once it was executed is considerable:

• Using the legitimate administrator session, they created another, unauthorised administrator account.
• Via a sham plugin (e.g. under the neutral name wp-smart-thumbnails), they installed a PHP web shell named emer-run.php – a tool that lets attackers run arbitrary code on the server.
• They set up persistent backdoors as so-called MU plugins (must-use plugins, which WordPress loads automatically and without any option to deactivate them in the dashboard).
• A stealth module hid the malicious accounts from the user list and the counters – so you won't see them in the normal WordPress dashboard.

Wordfence summarises the goal of the campaign unmistakably:

"The primary objective of this campaign is widespread, silent administrative persistence and remote code execution across millions of WordPress environments." (Source: Wordfence)

And perhaps the most important quote for putting this into context:

"No plugin update is required to become a victim. No file on disk is modified. The attack is entirely API-driven, invisible to file-based integrity scanners and barely visible to web application firewalls." (Source: Wordfence)

Who is affected?

Seven BdThemes plugin packages containing the Biggopti component are affected – most notably Element Pack Addons for Elementor with over 100,000 active installations. BdThemes advertises its overall portfolio with more than 350,000 active installations, according to BleepingComputer.

Important for context: These figures are not victim counts. So far there is no publicly confirmed number of compromised websites or affected personal data records. Whether your website was actually hit depends on two conditions:

1. An affected plugin version was actively installed during the exposure period.
2. A logged-in administrator opened the wp-admin page during that time.

Wordfence names 23 June 2026 as the earliest possible start of the campaign (the start date of the poisoned "Summer Sale" data set). Wordfence observed the campaign actively on 7 August 2026. The affected plugins were subsequently temporarily closed in the WordPress directory (Wordfence dates this to the 7th, BleepingComputer to 8 August).

Is there a patch?

Here the situation is sobering and important to understand: On 8 August 2026, the poisoned API endpoints were once again delivering clean JSON, according to Wordfence – so the manipulated delivery was stopped. But this does not remove any accounts, web shells or MU-plugin backdoors that have already been created.

For all seven plugins, Wordfence explicitly noted "No known patch available" on 8 August – i.e. no known secure version. Research up to 12 August 2026 found no solid evidence of a subsequently released secure plugin version or a re-release. BleepingComputer also reported on 10 August that BdThemes had not published any official statement at that time and had not responded to a media inquiry.

Consequence: Keep affected plugins deactivated. Do not trust any unconfirmed version. Reassess a reinstallation only after an explicit security release from the vendor and after a successful compromise assessment.

How to check whether you are affected

Because the attack actively hides itself, a glance at the WordPress dashboard is not enough. Proceed systematically:

1. Create a plugin inventory: Check under "Plugins" or via the file manager whether any of the seven BdThemes plugins is installed – and compare the version against the affected version ranges. Include deactivated plugins as well as staging and clone systems.
2. Determine the exposure window: Has an administrator opened wp-admin since 23 June 2026 while an affected version was active? If this is unknown, do not assume you are in the clear; instead, carry out the forensic checks.
3. Check users outside the dashboard: Since a stealth module can hide accounts, check the users directly in the database. Watch for unexpected administrators, suspicious email domains such as @wordpress.org or @developer.wordpress.org, and usernames matching the pattern bd_ plus six alphanumeric characters.
4. Search the file tree on the server side: Look for emer-run.php, unknown plugin directories such as wp-smart-thumbnails, and in the folder wp-content/mu-plugins for files such as class-wp-token-validate.php, class-wp-query-*.php and wp-cache-optimizer.php. Take into account the MD5 values and varying file names published by Wordfence.
5. Examine the database forensically: Look for the options fz_emer_login_tokens and fz_emer_done_v1, as well as recent changes to user and option data.
6. Analyse logs: Secure web, PHP and egress logs and look for connections to ia-cdn[.]com/fz/c or fetches of ia-cdn[.]com/fz/w2.js, as well as the endpoints named by Wordfence. The absence of hits is not proof of innocence, as logs may be incomplete or expired.
7. When in doubt, treat as compromised: If at least one indicator (IoC) is found, or if execution cannot be safely ruled out, treat the website as potentially fully compromised and bring in qualified incident-response support.

What you need to do now, specifically

1. Deactivate plugins immediately: Immediately deactivate all seven named BdThemes plugins in the affected versions and do not reactivate them until a verified security release is available. If functionally possible, uninstall them and plan a documented switch of the dependency.
2. If suspected, secure evidence first: Create a forensic copy of files, database, relevant logs and timestamps – before you clean up. Then isolate the website, or at least the administrative access, without hastily overwriting the original environment.
3. Remove unauthorised accounts and backdoors on the server side: Since the web shell could execute arbitrary PHP code, a clean restore from a backup created demonstrably before the exposure window is often more reliable than merely cleaning up individual files. Additionally, compare core, theme and plugin files against trustworthy original sources.
4. Rotate all credentials: After a suspected or confirmed case, renew all WordPress admin passwords, hosting/SFTP/SSH/panel access, database access, API and CDN keys, as well as WordPress security keys and salts. Terminate all existing sessions.
5. Set up server-side monitoring: Monitor new administrators, changes in wp-content/mu-plugins, outbound connections to command-and-control servers and suspicious plugin installations. Pure file-integrity checks are not sufficient here, because the initial infection occurred without any local plugin file being changed.
6. Strengthen baseline protection permanently: Minimise administrator privileges, enable multi-factor authentication for admins, maintain a plugin/theme inventory, keep backups offline or immutable, and reduce external resources in admin contexts as far as possible.

GDPR assessment

Note: This is general information, not legal advice.

A successful attack enabled unauthorised administrator privileges and PHP code execution. If your website contains personal data – for example from contact forms, customer, shop, newsletter or applicant data, or even log data – this may constitute a personal data breach. Whether a notifiable data breach exists does not follow automatically from the plugin installation. What matters is the actual or reasonably assumed accessibility of the data, the data categories and the risk to those affected.

Under Article 33 GDPR, a data breach must be reported to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it – unless it is unlikely to result in a risk to the rights and freedoms of natural persons. Where there is a high risk, the affected individuals must additionally be notified. The State Commissioner for Data Protection of Lower Saxony points out:

"Even if you do not have to submit a notification, you are subject to a documentation obligation for reviewing the process concerning the data breach in accordance with Article 33(5) GDPR."

If you work with a processor (such as an agency or a hoster), that party must report incidents to you as the controller without undue delay. Article 32 GDPR requires risk-appropriate technical and organisational measures. For violations, Article 83(4) provides for a fine of up to EUR 10 million or up to 2% of the total worldwide annual turnover of the preceding financial year – whichever is higher. This is not an automatic amount, but a case-by-case assessment. For the specific BdThemes incident, no publicly documented German sanction was identified in the sources reviewed.

Context: A pattern that is becoming more frequent

The BdThemes incident is part of a series of similar WordPress supply-chain attacks in the summer of 2026. On 28 July 2026, for example, the ARVE plugin (version 10.8.7) with around 20,000 active installations was reported as a critical backdoor (CVE-2026-18072, CVSS 9.8). And as early as 12 June 2026, a manipulated CDN script was active for a few hours at OptinMonster and TrustPulse – there too, only websites on which an administrator was logged in at the time were affected.

The common pattern: Attackers no longer target only the plugin on your server, but the external data streams behind it. File-based security scanners come up empty in the process.

Conclusion

If you use one of the seven affected BdThemes plugins, this is not a routine update matter, but a potential security incident. The situation is particularly urgent if an administrator has used the admin interface since 23 June 2026. Deactivate the affected plugins immediately, check on the server side for the indicators mentioned – and do not rely on the WordPress dashboard for this, because the attackers deliberately hide their traces.

Without a concrete indicator and without admin use during the exposure window, a compromise is not proven. But because of possible hidden accounts and files, a server-side examination is advisable in any case. Act now – and, if you suspect anything, bring in qualified support before you keep your website in public operation.