# How a Hijacked JSON Feed Handed Attackers the Keys to WordPress Admin Panels


The BdThemes supply-chain compromise didn't need to touch your site's files. It didn't need your credentials. It just needed your browser to do what WordPress plugins do every day: phone home.


That's the part that should keep WordPress administrators up at night.


## What Actually Happened


BdThemes builds premium WordPress design plugins — Element Pack, Prime Slider, Ultimate Post Kit, and others with installations numbering in the hundreds of thousands. Sometime before the incident was disclosed, a threat actor compromised the company's upstream infrastructure and modified a remote JSON feed that BdThemes plugins regularly fetch and serve to logged-in site administrators.


When a WordPress admin with an affected plugin installed opened their dashboard, their browser silently pulled down that feed — and with it, malicious instructions that created unauthorized administrator accounts on the victim's site. No file upload. No phishing link. No brute force. The site owner's own session delivered the payload.


The rogue accounts give attackers full control: they can install backdoors, redirect traffic, inject skimmers, exfiltrate data, or quietly maintain access for months before anyone notices. WordPress admin-level compromise is essentially game over for a site, and this attack achieved it without leaving traditional indicators in the plugin files themselves.


## Why This Attack Vector Is Harder to Catch Than It Looks


Most WordPress security advice focuses on the wrong layer.


File integrity monitoring, malware scanners, plugin update hygiene — all useful, all rendered largely irrelevant here. The malicious code didn't live in the plugin. It was served dynamically from BdThemes' own infrastructure, executed transiently in the browser, and used legitimate WordPress functionality to create the backdoor account. By the time a scanner looked at the installed plugin files, they were clean.


This is the Polyfill.io playbook applied to the WordPress ecosystem. When Sansec disclosed the Polyfill.io supply chain attack in June 2024, the mechanism was nearly identical: a legitimate JavaScript CDN was acquired, the served code was modified, and millions of sites that trusted that external resource became vectors overnight. The BdThemes incident follows the same logic — the plugin itself is trusted, the vendor's server is trusted, and that trust chain becomes the attack surface.


The JSON feed mechanism is particularly worth examining. BdThemes plugins, like many commercial WordPress tools, use remote feeds to deliver license data, template libraries, UI notices, or feature flags to the admin interface. These feeds are fetched with authenticated sessions, meaning the response is processed with admin-level browser privileges. An attacker who controls what that feed returns controls what happens next in the admin context.


This is not a flaw unique to BdThemes. It's a flaw in how the commercial WordPress plugin ecosystem has quietly normalized fetching and executing remote content as a feature.


## The Installed-Base Problem


BdThemes isn't a small developer. Element Pack Elementor Addons alone has over 500,000 active installations according to the WordPress plugin repository. Prime Slider claims comparable numbers. When a supply chain attack hits a vendor at that scale, the arithmetic is brutal: even a brief window of compromise, hitting a fraction of installations, potentially affects tens of thousands of sites.


And the sites running premium design plugins aren't random — they tend to be active, professionally managed properties: small businesses, agencies, e-commerce stores. Exactly the sites worth owning.


BdThemes has acknowledged the incident and pushed updates. The immediate question for site owners isn't whether to update — it's whether to audit. Rogue admin accounts created during the compromise window don't disappear when you update the plugin. They persist. If you were running affected BdThemes plugins during the exposure period and haven't audited your admin user list, you may still have an unwanted guest.


## What Defenders Need to Do Right Now


If you run BdThemes plugins:

  • Update all BdThemes products immediately
  • Go to Users → All Users in WordPress and sort by role — look for any Administrator accounts you don't recognize
  • Check account creation dates against the disclosure timeline
  • Review your activity log (Jetpack, WP Activity Log, or similar) for suspicious admin-level actions
  • Consider rotating all admin passwords and revoking application passwords and API keys

  • If you manage WordPress sites at scale:

  • Treat any plugin that fetches remote content and runs it in the admin context as a higher-risk dependency
  • If you have WAF or SIEM visibility into WordPress, look for unexpected user creation events
  • This incident is a reason to have user creation alerts, not just file change alerts

  • For the WordPress ecosystem broadly:

  • Plugin developers need to sign remote feeds and validate them client-side before execution
  • The WordPress Security Team should publish guidance on what remote content plugins are permitted to fetch and execute in authenticated contexts

  • ---


    ## HackWire Analysis


    The BdThemes incident lands at an uncomfortable moment for the WordPress security conversation, which has spent years focused on the wrong threats.


    The standard WordPress hardening advice — keep plugins updated, use strong passwords, enable 2FA, run a WAF — assumes the attack vector is an outsider trying to get in. Supply chain attacks invert the model. The attacker didn't try to get into your site. They got into BdThemes first, and then your site's own administrative session did the rest.


    This follows a pattern we've been tracking since at least the SolarWinds compromise made supply chain attacks mainstream: attackers are increasingly targeting the software development and distribution layer precisely because it's a force multiplier. Compromise one vendor, and you get the vendor's entire customer base as a secondary target — no individual site needs to be "hacked" in the traditional sense.


    What makes this particularly sharp for WordPress is the sheer density of third-party dependencies a typical site carries. A medium-complexity WordPress site might pull in 20 to 40 plugins, each of which may have its own remote feeds, update channels, and external API calls. That's 20 to 40 trust relationships with 20 to 40 separate vendor security postures, most of which site owners never evaluate.


    The rogue admin creation mechanism is also worth flagging for incident responders: this is the kind of compromise that doesn't show up in standard malware scans because the persistence mechanism is a legitimate WordPress user account, not a malicious file. Sites that were hit and cleaned up the plugin without auditing their user list are still compromised. The gap between "plugin updated" and "site secured" may be wider than most site owners realize.


    The broader implication: WordPress site security is now inseparable from WordPress vendor security. That's a problem the industry doesn't have good tooling or standards for yet.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)