# The WordPress Attack That Left No Fingerprints in the Code
When security teams audit a WordPress plugin for tampering, they look at the code. Files. Functions. Injected PHP. That's the playbook, and attackers targeting BdThemes just walked right past it.
Researchers at Wordfence confirmed a supply chain compromise hitting the popular WordPress plugin vendor — one that created rogue administrator accounts on victim sites without touching a single line of source code in the official WordPress.org repository. The vector was poisoned JSON, delivered through infrastructure that WordPress sites trusted implicitly because the plugin vendor told them to.
WordPress's own plugin team responded by temporarily pulling BdThemes downloads. But by then, the damage was already moving.
## How You Backdoor a Site Without Touching the Source
BdThemes publishes a portfolio of widely-used WordPress plugins — Element Pack, Prime Slider, and others with combined installation counts in the millions. Like most plugin vendors, BdThemes operates update infrastructure: servers that plugins phone home to, JSON-formatted update manifests that describe available versions, and endpoints that deliver plugin packages.
That JSON layer is where this attack lived.
WordPress plugins routinely fetch remote JSON to check for updates, validate licenses, retrieve configuration, or pull feature flags. When attackers compromised BdThemes' delivery infrastructure — not the WordPress.org code repository, but something upstream of it — they gained the ability to serve malicious JSON payloads to any site running an affected plugin. That JSON, when processed by the plugin, executed code to create a new WordPress administrator account with attacker-controlled credentials.
Wordfence researcher Paolo Tresso was direct about what made this unusual: "Unlike traditional software supply chain attacks, zero source code files were modified within the official WordPress.org repository." No git commits. No diff to inspect. The WordPress.org plugin team's own infrastructure — the canonical source of truth — remained clean throughout.
This is not an accident. It's a deliberate choice by attackers who understand how WordPress site owners and security tools think about trust.
## The Trust Hierarchy WordPress Built, and Its Gaps
WordPress's plugin ecosystem runs on layered trust. The WordPress.org repository is the root of that trust — code there is reviewed, and plugin teams pull versions directly from it. Security tools monitor WordPress.org installs, compare file hashes, and alert on modifications.
But many commercial plugins, particularly those with premium tiers, have their own licensing servers, update APIs, and CDN delivery pipelines that exist entirely outside the WordPress.org infrastructure. Sites running these plugins reach out to vendor-controlled endpoints on a regular schedule. That connection is authenticated only by a license key, and the data flowing back — often JSON — is processed by whatever parsing logic the plugin developer wrote.
The attack surface isn't the repository. It's the relationship between an installed plugin and its vendor's live infrastructure.
BdThemes was the vendor in this case, but nothing about this attack requires BdThemes specifically. Any plugin that fetches and processes remote data is a potential vector if the vendor's own infrastructure gets compromised. That's a much larger population than most WordPress administrators are thinking about.
## Rogue Admins: Still the Goal, Always
The objective here — creating unauthorized WordPress administrator accounts — is exactly what attackers want from WordPress compromises and has been for years. A rogue admin account is persistent, flexible, and hard to detect if you're not looking for it. From admin access, attackers can install backdoors, exfiltrate data, redirect traffic, inject malicious scripts into every page a site serves, or simply hold the access until they have a use for it.
This method of achieving that goal is what's new. Rather than exploiting an SQL injection flaw or a broken access control in the plugin itself, attackers used the plugin's legitimate update and configuration machinery against it. The plugin did exactly what it was designed to do — it just trusted data it shouldn't have.
## What Defenders Should Actually Do
If you're running any BdThemes plugin — Element Pack, Prime Slider, or anything else in their catalog — the immediate steps are:
Audit your WordPress administrator accounts. Look for accounts you didn't create, particularly those created recently or with unusual usernames. Any unfamiliar admin account should be treated as attacker-controlled until proven otherwise.
Check active sessions and recent logins. If an account was created and used, the access logs may tell you what happened next. WordPress logging is minimal by default — plugins like WP Activity Log or Simple History help here.
Verify plugin integrity. While the WordPress.org repository files appear uncompromised, any plugin files on your server that were modified outside of a normal update process are suspect. A file integrity scanner that has a known-good baseline is useful. Without a baseline, you're largely flying blind.
Temporarily disable automatic updates from third-party plugin vendors. This is a painful mitigation for sites that rely on those updates, but until BdThemes confirms their infrastructure is clean, automatic fetches are a risk.
## HackWire Analysis
This attack fits into a pattern that the security industry has been watching build for several years: supply chain compromise as the path of least resistance past hardened code review. The SolarWinds incident normalized the phrase "supply chain attack" for enterprise audiences, but the WordPress ecosystem faces a version of this risk that's distinctly harder to defend against — and affects a far larger number of small operators who have no security team to call.
The specific technique here — JSON poisoning through vendor-controlled update infrastructure — should be a wake-up call for the plugin development community. Most plugin vendors have given essentially no public thought to what happens if their own update servers are compromised. There's no standard for signing update manifests, no cryptographic verification that the JSON a plugin receives actually came from an uncompromised vendor, and no out-of-band notification system when something goes wrong.
Wordfence's rapid identification and the WordPress plugin team's response — pulling BdThemes downloads — was the right call, but it came after compromise. The detection was reactive. What the ecosystem genuinely needs is a prior-restraint model: cryptographically signed manifests that plugins verify against a public key embedded at install time, so a compromised vendor server can't silently push malicious data to millions of installed instances.
The "clean repository, dirty delivery" approach attackers used here will be repeated. The code in the repository is what gets audited. The delivery pipeline is where the trust actually breaks down. Until WordPress plugin standards address the full chain — source to installed site — this category of attack remains both viable and difficult to attribute before damage is done.
Vendors running premium plugin infrastructure should treat their update endpoints as high-value targets equivalent to their source code: multi-factor protected, continuously monitored, and subject to the same change-review controls applied to code commits.
— HackWire Editorial
---
## Related Coverage