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

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 - Attackers gained write access to the static storage of BdThemes (equivalent to DigitalOcean Spaces). - They injected a string containing an attribute escape and onanimationstart into thedisplay_id field of the Biggopti JSON response. - Affected plugins fetched the promotional JSON on every admin_init . - The logged-in administrator's browser concatenated the unescaped value into the id attribute of the DOM. - The CSS animation triggered the event handler in about 10 milliseconds. - The browser fetched and executed an external script ( w2.js orx.js from the vendor domain). Chain B: Full Compromise via w2.js - It sent the site origin to ia-cdn[.]com/fz/c to receive targeting instructions. - It used the current administrator session's X-WP-Nonce to create an administrator account via the REST API or standard forms. - It uploaded a fake plugin (such as wp-smart-thumbnails ). - It executed the emer-run.php web shell via URL access. - It deployed a magic-login module and a stealth module to wp-content/mu-plugins . - It enabled unauthenticated administrator login via ?wplogin= . - It hooked WordPress database queries to hide the created account and user count from the admin dashboard. - It sent the results of each step back to the C2 using navigator.sendBeacon . Chain C: x.js Alternative Payload - It hashed the site hostname to generate a deterministic username ( bd plus 6 characters) and password. - It extracted the nonce from user-new.php and created an administrator account. - It sent the status, username, password, and site URL to the C2. - 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 - 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} a**@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 - Identify affected plugins, versions, and admin panel access times. - Preserve web, proxy, DNS, browser history, WordPress database, and filesystem snapshots. - Look back beyond August 7, extending the timeframe to the earliest possible start date of June 23. - 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 andfz_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 , andia-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