The WordPress Security Nightmare: How 100,000 Sites Were Hacked in One Blow published: true

File Integrity Monitoring (FIM) tools reported 0 modifications and a 100% clean status, yet over 100,000 WordPress sites were compromised simultaneously in a single, coordinated supply chain attack.

If you rely solely on local code audits or repository checksums to keep your web applications safe, this breach is a massive wake-up call for modern web architecture.

I just published a full technical video breakdown analyzing how this attack unfolded, and here is a brief rundown of what happened under the hood.

1. Bypassing WordPress.org Repositories Entirely

The attackers didn't bother tampering with the official WordPress.org plugin repository. Instead, they targeted the vendor's upstream cloud infrastructure (specifically, a DigitalOcean Spaces bucket) powering dynamic promotional banners within the BigOpti component shipped with BdThemes plugins.

By gaining write access to this third-party storage, they served poisoned JSON responses directly to end-user servers.

2. Zero-Click Stored XSS via Unescaped JSON

The BigOpti component fetched JSON data containing a display_id parameter. The application failed to sanitize or escape this parameter on the client side before rendering it in wp-admin.

{
  "status": "success",
  "display_id": "<script>execute()</script>",
  "promotions": [...]
}

Because the input was rendered live as executable code, the XSS payload triggered silently the exact moment any logged-in administrator opened their WordPress dashboard. Zero clicks required from the attacker.

3. Automated Persistence & The w2.js Payload

Triggered via the api-data-all-records endpoint, the w2.js script immediately initiated three automated routines:

1. C2 Connection: Contacted command-and-control servers (a-cdn.com) for targeting instructions.
2. Rogue Admin Account: Created an admin-level user directly inside the database.
3. Web Shell Extraction: Dropped emer-run.php via a fake plugin upload and created hidden scripts inside wp-content/mu-plugins/ (including a URL parameter backdoor: ?_wplogin=).

4. Algorithmic Credential Generation (x.js)

In parallel, an alternate payload (x.js) eliminated the need for attackers to maintain a centralized database of compromised sites.

It extracted the target site's hostname, passed it through a Base36 hashing algorithm, and derived deterministic admin credentials on demand:

Host: target-site.com ---> Base36 Hash ---> Username: bd_[hash] / Password: Bd@26![hash]x

Knowing only the URL of a victim site allowed the attackers to calculate valid admin login credentials instantly.

Why Traditional Security Tools Failed

Standard File Integrity Monitors scan local disk files against pristine source code checksums. Because the core plugin files on disk matched the clean, official repository versions, local scanners saw zero anomalies. The malicious payload was pulled dynamically at runtime over the network.

Key Takeaways for Developers:

• Never Trust Remote API Streams: Always sanitize, escape, and validate remote JSON payloads before rendering them in the DOM.
• Enforce Strict Content Security Policies (CSP): Restrict inline script execution and limit where external API requests can be dispatched.
• Monitor Network Traffic: Security monitoring must include egress/ingress network traffic inspection, not just disk scans.

🎥 Watch the Full Video Walkthrough:

Check out the full video above for a visual, line-by-line breakdown of the exploit chain, database hooking mechanics, and C2 infrastructure connections.

How is your team handling runtime validation for third-party API payloads? Let's discuss in the comments below!