BdThemes Supply-Chain Compromise: Rogue WordPress Admin Accounts — Detection and Remediation Guide

A threat actor compromised the upstream infrastructure of BdThemes — a developer of premium WordPress web-design plugins — and modified a remote JSON feed delivered to site administrators' browsers. That tampered feed was then leveraged to create rogue administrator accounts on customer WordPress sites. This is a classic trusted-channel supply-chain attack: no vulnerability in your site was exploited, no credentials were phished. The malicious logic arrived through a legitimate plugin feature your site already trusted.

If your organization runs any BdThemes product (widely distributed design/addon plugins for popular page builders), you must assume exposure until proven otherwise. Rogue admin accounts are a durable foothold: attackers use them to install backdoored plugins, inject skimmers, deploy SEO spam, and pivot into the underlying host. Treat this as an incident, not a patch-and-forget event.

Technical Analysis

What was compromised

• Affected products: WordPress sites running BdThemes premium plugins/addons that fetch a remote JSON feed rendered in the administrator dashboard (wp-admin). Any version that retrieves the upstream feed is potentially affected — the malicious content was served server-side by the vendor's own infrastructure, so updating alone does not retroactively clean already-created accounts.
• Attack vector: Supply-chain compromise of the vendor's update/feed infrastructure. The attacker modified a JSON response consumed by admin-facing plugin code. Because the feed executes/renders in an authenticated administrator's browser session (or via server-side plugin logic), the attacker effectively inherited admin-level privileges without touching site credentials.
• Impact mechanism: Creation of unauthorized WordPress administrator accounts — achieved through the site's own legitimate user-creation pathways (/wp-admin/user-new.php, the REST API endpoint /wp-json/wp/v2/users, or direct AJAX actions such as admin-ajax.php calls). From a defender's perspective, the observable artifact is the same regardless of the exact injection path: an admin account created at a time, from a source IP, or via a request pattern you did not authorize.
• CVE: No CVE identifier has been published in the source reporting for this campaign. Track vendor advisories and Wordfence/Patchstack feeds for a formal assignment.

Why this technique matters

Supply-chain attacks against WordPress plugin vendors scale brutally well. A single upstream compromise reaches every site running the affected plugin, and because the payload rides a legitimate channel, perimeter controls (WAF signatures, plugin vulnerability scanners keyed to CVEs) are blind to it. The attack chain also defeats the common assumption that "admin account creation = someone logged in with stolen creds." Here, the creation event is triggered by trusted code.

Exploitation status

Confirmed active exploitation in the wild. This is not theoretical: rogue admin accounts have been observed on customer sites following the feed tampering. Treat any site with a BdThemes plugin installed during the exposure window as potentially compromised.

Detection & Response

The highest-fidelity detection surface is WordPress user-creation activity that does not correlate with legitimate administrative work. Below are production-ready analytics targeting that behavior. Tune the time windows and known-admin lists before deployment — the goal is to catch unauthorized account creation, not your marketing team adding an editor.

SIGMA

The following rules target web server access logs (Apache/Nginx/IIS) for WordPress user-creation endpoints. Deploy them against your web access log pipeline.

---
title: WordPress Admin Account Creation via user-new.php
tid: 3f8a2c91-7b4d-4e5a-9c12-bd0e6f1a8d33
status: experimental
description: Detects POST requests to the WordPress user creation endpoint, which may indicate rogue admin account creation following the BdThemes supply-chain compromise. Correlate with authorized change windows and known administrator source IPs.
references:
  - https://www.bleepingcomputer.com/news/security/bdthemes-plugins-supply-chain-hack-creates-rogue-wordpress-admins/
  - https://attack.mitre.org/techniques/T1136/001/
author: Security Arsenal
date: 2026/04/09
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|endswith: '/wp-admin/user-new.php'
  condition: selection
falsepositives:
  - Legitimate administrator user provisioning
  - Managed WordPress hosting automation
level: high
---
title: WordPress User Creation via REST API
tid: 9d4e7b22-1a6c-4f83-b8e5-5c2a9d0f3b71
status: experimental
description: Detects POST requests to the WordPress REST API users endpoint, a common path for scripted rogue account creation including attacks delivered via compromised plugin code and tampered remote feeds.
references:
  - https://www.bleepingcomputer.com/news/security/bdthemes-plugins-supply-chain-hack-creates-rogue-wordpress-admins/
  - https://attack.mitre.org/techniques/T1136/001/
author: Security Arsenal
date: 2026/04/09
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains: '/wp-json/wp/v2/users'
  condition: selection
falsepositives:
  - Headless WordPress integrations and legitimate provisioning scripts
level: high
---
title: Suspicious WordPress admin-ajax Activity Followed by User Creation
tid: 5b1c8f44-2d9a-4c67-a3e1-8f7d2b6c4a95
status: experimental
description: Detects POST requests to admin-ajax.php from external or non-admin referers, a pattern consistent with injected JavaScript from a compromised remote feed triggering privileged actions in an administrator session.
references:
  - https://www.bleepingcomputer.com/news/security/bdthemes-plugins-supply-chain-hack-creates-rogue-wordpress-admins/
  - https://attack.mitre.org/techniques/T1195/002/
author: Security Arsenal
date: 2026/04/09
tags:
  - attack.initial_access
  - attack.t1195.002
logsource:
  category: webserver
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|endswith: '/wp-admin/admin-ajax.php'
    cs-referer|contains:
      - 'http://'
      - 'https://'
  filter_same_site:
    cs-referer|contains:
      - '/wp-admin/'
  condition: selection and not filter_same_site
falsepositives:
  - Frontend AJAX features from legitimate themes and plugins
level: medium

The third rule intentionally fires more broadly — use it as a hunting pivot, not a paging alert. The two user-creation rules are your high-signal detections.

KQL (Microsoft Sentinel / Defender)

This query hunts web access logs ingested via IIS logs, CEF, or Syslog for WordPress account-creation activity, and flags requests that did not originate from your known administrator IP ranges. Populate the KnownAdminIPs list before running.

let KnownAdminIPs = dynamic(["203.0.113.10", "198.51.100.25"]);
let Lookback = 14d;
union isfuzzy=true
    (W3CIISLog
    | where TimeGenerated > ago(Lookback)
    | where csMethod == "POST"
    | where csUriStem has_any ("user-new.php", "/wp-json/wp/v2/users", "user-edit.php")
    | extend SourceIP = cIP, Uri = csUriStem, Table_ = "W3CIISLog"),
    (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where RequestMethod == "POST"
    | where RequestURL has_any ("user-new.php", "/wp-json/wp/v2/users", "user-edit.php")
    | extend SourceIP = SourceIP, Uri = RequestURL, Table_ = "CommonSecurityLog")
| where SourceIP !in (KnownAdminIPs)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), RequestCount = count(), Tables = make_set(Table_)
  by SourceIP, Uri
| sort by RequestCount desc

Also worth hunting: wp-login.php authentication events from the rogue account's IP after creation — rogue admins are created to be used.

Velociraptor VQL

This artifact hunts web server access logs on the WordPress host for user-creation requests. Deploy it against your web servers to scope the compromise across the fleet.

-- Hunt Apache/Nginx access logs for WordPress user creation activity
SELECT
    parse_string_with_regex(regex='^(?P<SrcIP>[0-9.]+) .* \[(?P<Timestamp>[^\]]+)\] "(?P<Method>[A-Z]+) (?P<URI>[^ ]+)', string=Line) as Parsed,
    FullPath
FROM foreach(
    row={
        SELECT FullPath FROM glob(globs=['/var/log/apache2/*access*log*', '/var/log/nginx/*access*log*'])
    },
    query={
        SELECT FullPath, Line FROM parse_lines(filename=FullPath)
        WHERE Line =~ 'POST' AND Line =~ '(user-new\\.php|wp-json/wp/v2/users)'
    })

Pair this with a WordPress-level check: dump the wp_users table joined against wp_usermeta (capability administrator) and diff against your provisioning records. Any administrator row you cannot attribute to a person and a change ticket is a rogue account until proven otherwise.

Remediation Script

Run this on each affected WordPress host. It inventories administrator accounts, searches recent access logs for user-creation requests, and checks plugin file integrity.

#!/bin/bash
# BdThemes supply-chain triage - run as root or with sudo on the WordPress host
WP_PATH="/var/www/html"

echo "=== [1] Enumerate WordPress administrator accounts ==="
# Requires WP-CLI; adjust --path to your docroot
sudo -u www-data wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --path="$WP_PATH"

echo "=== [2] Search access logs for user-creation endpoints (last 30 days of logs) ==="
grep -hE 'POST .*(user-new\.php|wp-json/wp/v2/users|user-edit\.php)' \
  /var/log/apache2/*access*.log* /var/log/nginx/*access*.log* 2>/dev/null \
  | awk '{print $1, $4, $7}' | sort | uniq -c | sort -rn | head -50

echo "=== [3] Identify recently modified files in plugin directories ==="
find "$WP_PATH/wp-content/plugins" -type f -mtime -30 \( -name '*.php' -o -name '*.js' \) -printf '%T+ %p\n' | sort -r | head -40

echo "=== [4] Check WordPress core integrity ==="
sudo -u www-data wp core verify-checksums --path="$WP_PATH"

echo "=== [5] List installed BdThemes-related plugins and versions ==="
sudo -u www-data wp plugin list --path="$WP_PATH" | grep -iE 'bdthemes|element-pack|prime-slider'

echo "=== [6] Flag administrator sessions - force logout all users after cleanup ==="
echo "Run after credential rotation: sudo -u www-data wp user reset-password <admin_id> --path=$WP_PATH"
echo "Then rotate security keys/salts in wp-config.php to invalidate all sessions."

Remediation

1. Scope immediately. Inventory every WordPress site in your estate running BdThemes products (e.g., Element Pack, Prime Slider and related addons). Use your CMS asset inventory or the WP-CLI command in the script above.
2. Audit administrator accounts. Export the full administrator list for each site and reconcile against HR/provisioning records. Delete any account you cannot attribute. Check the user_registered timestamp against the known exposure window reported by BdThemes/BleepingComputer.
3. Check for persistence beyond the rogue account. Rogue admins are a means, not an end. Review installed plugins/themes for unknown additions, inspect wp-content/uploads for PHP files, check for unauthorized scheduled tasks (wp cron event list), and look for modified core files (wp core verify-checksums).
4. Update BdThemes plugins to the latest clean release per the vendor's advisory — but understand that updating removes the malicious feed mechanism only; it does not remove accounts or backdoors already planted. Consult the official BdThemes security notice and the BleepingComputer report for the current clean version numbers before redeploying.
5. Rotate everything. Reset passwords for all legitimate administrator accounts, rotate WordPress security keys/salts in wp-config.php (this invalidates all active sessions), and rotate any API keys, database credentials, or FTP/SFTP accounts associated with the site.
6. Block and monitor. Add the user-creation Sigma rules above to your web log pipeline, alert on administrator role grants in WordPress audit logs (a plugin such as WP Activity Log or your existing log forwarder), and monitor for outbound requests from wp-admin pages to unexpected third-party domains.
7. Harden the admin surface going forward. Restrict /wp-admin and xmlrpc.php by IP allowlist or VPN where operationally feasible, enforce MFA on all administrator accounts, and disable the REST API user endpoint for unauthenticated requests if not required.
8. If compromise is confirmed: preserve logs and a forensic image before cleanup, notify per your IR plan and regulatory obligations, and treat the host as untrusted until rebuilt or thoroughly validated.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub