BdThemes API-Driven Supply Chain Compromise: Admin XSS to Web Shell and Hidden Admin

1. Basic Information

• Article Title: PSA: Supply Chain Compromise in BdThemes Ecosystem via Poisoned API Response
• Publisher: Wordfence Threat Intelligence
• Publication Date: August 8, 2026
• Original Source: Wordfence
• Related Sources: BleepingComputer
• Related Attacks: Linked to the same C2 as the Advanced Responsive Video Embedder / OptinMonster supply chain compromises
• Affected Products: Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste, Smart Admin Assistant
• Vulnerability: DOM XSS in the admin dashboard caused by unescaped display_id output in the Biggopti Library (CVE unassigned, reported as unfixed)
• Severity: Critical

Wordfence observed active attacks on August 7. The compromise did not affect the plugin files on WordPress.org. Instead, it affected the static JSON and JavaScript delivery path from BdThemes that plugins fetch inside the admin dashboard.

2. Executive Summary

Attackers placed malicious JSON into the vendor's object storage. When a logged-in WordPress administrator simply opened wp-admin, it triggered a DOM XSS vulnerability in a legitimate plugin. Using the administrator's session privileges, the attack automatically created a new administrator, dropped a web shell, established MU-plugin persistence, and hid the unauthorized account.

3. Attack Flow

Chain A: Malicious Feed to Administrator Session Execution

1. Attackers gained write access to the static storage of BdThemes (equivalent to DigitalOcean Spaces).
2. They injected a string containing an attribute escape and onanimationstart into the display_id field of the Biggopti JSON response.
3. Affected plugins fetched the promotional JSON on every admin_init.
4. The logged-in administrator's browser concatenated the unescaped value into the id attribute of the DOM.
5. The CSS animation triggered the event handler in about 10 milliseconds.
6. The browser fetched and executed an external script (w2.js or x.js from the vendor domain).

Chain B: Full Compromise via w2.js

1. It sent the site origin to ia-cdn[.]com/fz/c to receive targeting instructions.
2. It used the current administrator session's X-WP-Nonce to create an administrator account via the REST API or standard forms.
3. It uploaded a fake plugin (such as wp-smart-thumbnails).
4. It executed the emer-run.php web shell via URL access.
5. It deployed a magic-login module and a stealth module to wp-content/mu-plugins.
6. It enabled unauthenticated administrator login via ?_wplogin=<token>.
7. It hooked WordPress database queries to hide the created account and user count from the admin dashboard.
8. It sent the results of each step back to the C2 using navigator.sendBeacon.

Chain C: x.js Alternative Payload

1. It hashed the site hostname to generate a deterministic username (bd_ plus 6 characters) and password.
2. It extracted the nonce from user-new.php and created an administrator account.
3. It sent the status, username, password, and site URL to the C2.
4. It saved a completion flag in localStorage to prevent duplicate execution.

4. Attacker Position and Execution Location

• The attacker had write access to the cloud storage or internal content delivery infrastructure of BdThemes.
• The initial code executed inside the authenticated administrator's browser, not on the target site's server.
• Account creation, plugin installation, and web shell execution took place on the victim's WordPress server.
• The MU-plugins and database options served as server-side persistence points, while localStorage maintained the browser-side execution state.

5. Visibility to Victims and Administrators

Administrators simply opened wp-admin as usual. No update actions or additional authentication requests were required. Because the core plugin files remained unmodified, file integrity checks against the WordPress.org repository missed the initial execution. Even after the compromise, the stealth module could hide unauthorized administrators from the user list and total count. However, unknown MU-plugins, fake plugins, emer-run.php, database options, and C2 traffic remained observable.

6. Success and Failure Conditions

Success Conditions

• Affected plugins and unescaped display_id handling were present.
• An administrator viewed wp-admin while the malicious response was active.
• The browser was able to communicate with external scripts and the C2.
• The administrator session had permissions to create users and upload plugins.
• MU-plugin and web root write activities were not detected or blocked.

Failure Conditions

• Restoration of vendor response integrity and XSS patching.
• Context-appropriate escaping and sanitization when inserting external data into attributes and the DOM.
• Blocking unauthorized scripts and outbound connections via Content Security Policy (CSP) in the admin dashboard.
• Segregated administrator plugin installation permissions, change approvals, and File Integrity Monitoring (FIM).
• Early detection of WordPress users, MU-plugins, database options, and C2 traffic.

7. What Happens on Success

The attacker gains full site control, arbitrary code execution via web shell, unauthenticated magic login, hidden administrators, and persistent MU-plugins. Attackers can execute content defacement, deploy additional malware, steal credentials, distribute malware to visitors, or pivot to other sites. However, the later uses are not individually confirmed in public sources and remain Inferences.

8. Observable Logs

Email

• No email was required for initial access. Subsequent activities might include suppressed notification or password reset emails from compromised administrators, or suspicious outbound emails.

Proxy / SWG / DNS

• Biggopti endpoint api[.]sigmative[.]io, ia-cdn[.]com/fz/w2.js, and /fz/c.
• Script retrieval and beaconing immediately after viewing wp-admin.
• Unusual C2 communication from WordPress administrative devices.

Endpoint / EDR

• Browser process on the administrator device communicating with C2 and writing completion flags to localStorage.
• Server-side files: emer-run.php, wp-smart-thumbnails, class-wp-token-validate.php, class-wp-query-*.php, wp-cache-optimizer.php.
• MU-plugins with modification times backdated to September 2025.

Identity / IdP

• Administrators with usernames matching bd_[0-9a-z]{6} and @wordpress.org / @developer.wordpress.org style emails.
• User creation and plugin installation originating from legitimate administrator sessions.
• Unauthenticated magic logins using ?_wplogin=.

SaaS / Cloud

• Write operations, object versions, access key usage, and Cloudflare access logs on vendor storage buckets.
• Time-correlated audits of WordPress hosting and object storage.

Network

• HTTP(S) traffic from the victim WordPress site to the C2.
• Direct requests to web shells, plugin uploads, and MU-plugin creation.
• Browser-to-C2 connections from the admin panel, even without file differences.

9. Attack Success Determination

• Contact Only: The affected plugin fetched malicious JSON, but no events fired and no follow-up communication occurred.
• User Action: An administrator viewed wp-admin during the active delivery window.
• Initial Execution: Retrieval of w2.js / x.js, C2 verification, and nonce retrieval.
• Malware or Authentication Success: Confirmation of rogue administrators, fake plugins, emer-run.php, or MU-plugins.
• Data Theft / Session Compromise: Beacons containing created credentials or execution results, and successful magic login.
• Follow-on Compromise: Web shell commands, content defacement, additional payloads, or credential reuse on other sites.

10. Investigation Playbook

Trigger

Detection of affected plugins, ia-cdn[.]com, suspicious administrators, unknown MU-plugins, emer-run.php, or ?_wplogin=.

Initial Checks

1. Identify affected plugins, versions, and admin panel access times.
2. Preserve web, proxy, DNS, browser history, WordPress database, and filesystem snapshots.
3. Look back beyond August 7, extending the timeframe to the earliest possible start date of June 23.
4. Do not rely solely on file differences from the WordPress.org repository.

Endpoints

• Administrator device URLs, caches, localStorage, and C2 communications.
• Server plugins, MU-plugins, web roots, file modification times, hashes, and PHP access logs.

Authentication & Cloud

• Enumerate all administrators directly from the database and compare with the UI display.
• Check options such as fz_emer_login_tokens and fz_emer_done_v1.
• Immediately rotate storage credentials if managed by your organization.

Subsequent Actions

• Search for web shell requests, additional files, outbound traffic, post/theme alterations, and credential usage.
• Hunt across other WordPress sites managed by the same administrators.

Containment

• Isolate or place the site in maintenance mode, preserve evidence, and remove known backdoors.
• Rotate WordPress, hosting, database, API credentials, and session salts.
• Investigate administrator devices and restore from trusted backups or rebuild.

Determination Categories

Feed Contact / Admin Page Loaded / Script Executed / Rogue Admin / Web Shell / Persistent Backdoor / Follow-on Compromise

11. Defense and Detection Ideas

Single Events

• Administrators with names matching bd_ + 6 characters, unknown MU-plugins, emer-run.php, and ia-cdn[.]com.
• sendBeacon requests from the administrator browser, plugin uploads, and ?_wplogin=.

Time-Series Correlation

Admin panel view → Vendor JSON retrieval → External JS → User creation → Plugin upload → Web shell → MU-plugin → C2 beacon

Threat Hunting Perspectives

• Administrators existing in the database but hidden from the UI.
• Files created in 2026 with modification times artificially backdated to September 2025.
• External JavaScript execution and beacons immediately following admin panel views.
• Multiple sites sharing the same C2, file hashes, or naming conventions.

Log Gaps

• Administrator browser URLs/networks, WordPress REST and admin actions, database queries, and MU-plugin FIM.
• Hosting egress traffic, object storage object versions, and write identities.

Priority Countermeasures

1. List affected sites and directly audit all administrators and MU-plugins.
2. Disable affected plugins until vendor patches and re-releases are confirmed.
3. Block C2 and IOCs, and hunt across web roots, database options, and user tables.
4. Segregate administrator plugin installation permissions and implement change approvals.

12. Facts / Inference / Hypothesis

Facts

• Plugin distribution files on WordPress.org were not modified; the remote JSON feed was poisoned.
• The unescaped display_id entered DOM attributes, allowing XSS to fire on every administrator wp-admin page load.
• w2.js implemented rogue administrator creation, web shells, magic login, account hiding, and result beaconing.
• x.js generated deterministic administrator credentials based on the hostname.
• Active attacks were observed on August 7, and the endpoint returned to clean JSON on August 8.

Inference

• File integrity monitoring alone cannot detect initial execution; administrator browser telemetry and SaaS/hosting logs are required.
• Deterministic credentials suggest the attackers were designed to re-enter systems without maintaining a central victim ledger.
• Once a web shell is established, all secrets within WordPress must be treated as compromised.

Hypothesis

• The initial access vector for the storage credentials may have been phishing, CI/CD secret leakage, or internal compromise, though unconfirmed.
• Previously compromised sites linked to the same C2 campaign may have been reused.

13. MITRE ATT&CK Mapping

High Confidence

• T1195.002 Compromise Software Supply Chain
• T1189 Drive-by Compromise
• T1136.001 Create Account: Local Account
• T1505.003 Server Software Component: Web Shell
• T1071.001 Application Layer Protocol: Web Protocols
• T1070.006 Indicator Removal: Timestomp
• T1562.001 Impair Defenses: Hiding administrator lists and counts

Medium Confidence

• T1041 Exfiltration Over C2 Channel: Sending execution results and credentials via beacons
• T1098 Account Manipulation: Maintaining continuous access via magic-login tokens

14. Unknowns and Further Investigation

• Initial access vectors to vendor storage and the identities using access keys.
• The complete version range of affected plugins, patched versions, and CVE status.
• The target audience, duration, geographic regions of malicious responses, and actual victim count.
• Web shell post-exploitation commands, secondary payloads, and data theft confirmation.
• Infrastructure and actor overlaps with other campaigns using the same C2.

15. Impact on Global SOCs and Enterprises

Content Management Systems (CMS) like WordPress and Elementor are widely used globally for corporate websites, portals, and e-commerce platforms. Because the attack executes purely within the administrative dashboard without requiring file updates to plugins, traditional file integrity monitoring and WAF solutions are insufficient. Security Operations Centers (SOCs) must expand their scope beyond web servers to include CMS administrator browsers, WordPress databases, MU-plugins, and hosting egress traffic as a unified investigation boundary.

16. Summary

For SOCs

• Correlate admin panel access since June 23 with C2 traffic, user creation, and plugin uploads.
• Enumerate administrators directly from the database rather than the UI, and inspect MU-plugins and database options.
• Categorize incidents into stages: feed contact, script execution, administrator creation, web shell deployment, and follow-on compromise.

For Administrators

• Temporarily disable affected plugins and only re-enable them after vendor patches are applied.
• Audit administrators, MU-plugins, web roots, and database options, and rotate credentials.
• Restrict direct administrator plugin installation permissions, and implement CSP and egress controls.

For Users

• The attack does not rely on actions by general visitors; it succeeds when CMS administrators open the admin dashboard.
• Administrators who accessed the admin panel during the target window should cooperate with SOC terminal and site investigations, even if no anomalies are visible.