Listen to this Post
Introduction: When Trusted WordPress Tools Become the Attack Vector
WordPress attacks are often imagined as obvious vulnerabilities: an outdated plugin, a stolen password, a malicious upload, or a suspicious file suddenly appearing on a server. The latest BdThemes incident is far more unsettling because it demonstrates how attackers can abuse something that looks completely legitimate—the normal communication between a WordPress plugin and its developer.
The incident involves BdThemes, a developer of premium WordPress design and functionality tools whose products collectively have hundreds of thousands of active installations. According to research from Defiant’s Wordfence team, attackers compromised infrastructure associated with the vendor and poisoned a remote JSON feed consumed by affected plugins.
The result was a supply-chain attack in which malicious JavaScript could execute inside the browser of an authenticated WordPress administrator.
That distinction matters.
The plugins themselves did not necessarily need to be replaced with malicious versions. Instead, the attacker manipulated data that the plugins were already programmed to trust.
This created a particularly dangerous scenario: an administrator could simply open a normal wp-admin page and unknowingly trigger malicious code.
The campaign reportedly went as far back as June 23, 2026, while Wordfence began observing related attacks on August 7. WordPress subsequently removed the affected BdThemes products from WordPress.org while an investigation was underway.
For WordPress site owners, this is another reminder that modern supply-chain attacks are increasingly moving beyond malicious package updates. APIs, CDNs, remote configuration systems, JavaScript libraries, telemetry endpoints, promotional feeds, and cloud storage can all become part of an attacker’s delivery mechanism.
The BdThemes Ecosystem: A Large WordPress Footprint
BdThemes is known for a range of WordPress products aimed at extending Elementor and other website-building workflows.
Among the affected ecosystem are products such as Element Pack, Prime Slider, Ultimate Post Kit, Pixel Gallery, and Ultimate Store Kit.
Element Pack alone has more than 100,000 active installations listed on WordPress.org, while BdThemes has promoted a broader portfolio exceeding 350,000 active installations.
That scale turns an infrastructure compromise into something much more significant than an isolated website breach.
A vulnerability affecting one small WordPress plugin might expose thousands of websites. A compromised developer ecosystem can potentially create a pathway into an entire population of unrelated websites that trust the same vendor.
The Attack Did Not Depend on a Traditional Plugin Update
One of the most concerning aspects of the incident is that the attack reportedly did not require victims to download a new malicious plugin version.
Instead, the attackers allegedly obtained write access to a storage bucket used by the vendor and modified a remote JSON data stream.
That JSON data was consumed by an administrative promotional-banner component.
On paper, this sounds harmless.
In reality, it became the
The Biggop Library Became the Weak Link
The vulnerable functionality was associated with the Biggop Library, used by the Biggopti component to retrieve promotional content from the vendor’s API infrastructure.
The problem reportedly originated from code introduced in March 2026.
The library processed information received from the remote API without sufficient output escaping. Specifically, Wordfence identified the display_id parameter as a source of cross-site scripting exposure.
That meant trusted remote content could potentially become executable browser code.
The distinction between “data” and “code” effectively disappeared.
Remote JSON Became Executable JavaScript
Normally, a promotional JSON response might contain information such as a banner title, destination URL, image, or campaign identifier.
The application assumes that the server providing that information is trustworthy.
But once attackers gained the ability to modify the remote response, they could insert content specifically designed to exploit the vulnerable parsing process.
The application then delivered that content into an administrator’s browser.
This is the essence of the attack.
The attacker did not necessarily have to compromise every WordPress site individually. Instead, the attacker compromised the trusted channel connecting those sites to the vendor.
Why an
The malicious JavaScript reportedly executed in the security context of a logged-in WordPress administrator.
That is enormously valuable to an attacker.
A normal visitor may have very limited privileges. A WordPress administrator, however, can create users, install plugins, change settings, modify content, upload files, and potentially execute actions that ultimately lead to complete site compromise.
The browser effectively became the
Rogue Administrator Accounts Created Silently
According to
This is where the incident moves from a conventional XSS vulnerability into a serious supply-chain compromise.
The attacker was not merely stealing information from the browser.
The malicious code could use the
A site administrator could therefore unknowingly perform the attacker’s commands simply by visiting the WordPress dashboard.
The Attack Could Also Establish Persistence
The campaign reportedly went further.
Researchers identified an additional payload referred to as w2.js, which could establish persistence through a webshell named emer-run.php.
The mechanism reportedly involved installing a fake plugin.
This is significant because the original malicious JavaScript delivery mechanism does not necessarily need to remain available forever once persistence has been established.
The attacker can potentially move from:
Remote feed → Browser execution → Administrator privileges → Rogue account → Persistent webshell
That is a classic escalation chain disguised behind legitimate software functionality.
Hiding the Rogue Accounts Made Detection Harder
The attack reportedly included another particularly stealthy technique: manipulating WordPress database queries so that malicious administrator accounts would not appear normally in the administrator list.
That means a site owner could inspect the WordPress dashboard and see what appears to be a normal collection of administrators.
The compromised account could still exist underneath.
This creates a dangerous gap between what the administrator sees and what the database actually contains.
In cybersecurity, that difference is often where persistence survives.
The Most Dangerous Feature: No User Interaction
Perhaps the most troubling characteristic of the campaign is its lack of obvious victim interaction.
There was reportedly no requirement for the administrator to install a suspicious update.
No malicious attachment needed to be opened.
No executable needed to be downloaded.
No unfamiliar plugin necessarily had to be installed.
The administrator simply needed to access a WordPress administration page where the affected component was active.
The remote API response did the rest.
Why This Is a Supply-Chain Attack
A traditional vulnerability attacks the software directly.
A supply-chain attack attacks the trust relationship surrounding that software.
In this case, websites trusted BdThemes.
BdThemes’ plugins trusted their remote infrastructure.
The
The administrator trusted the WordPress dashboard.
The attacker exploited the chain.
This is why supply-chain security has become increasingly important for WordPress and other software ecosystems.
The Attack Reportedly Started Earlier Than Discovery
Defiant researchers determined that the earliest possible beginning of the campaign was June 23.
The security team began observing attacks through Wordfence on August 7.
That gap illustrates a familiar problem in cybersecurity: attackers can remain active long before defenders understand what they are looking at.
A compromised infrastructure component can quietly distribute malicious content for weeks before detection.
WordPress Took the Affected Products Offline
Following the discovery, the affected BdThemes plugins were removed from the WordPress.org directory on August 8 pending investigation.
Two poisoned API endpoints reportedly began returning clean JSON data.
Removing the plugins from the official directory is an important containment measure, but it does not automatically clean websites that may already have been compromised.
That distinction is critical.
Removing the delivery mechanism is not the same thing as removing persistence.
A Clean API Does Not Prove a Clean Website
This is one of the biggest lessons from the incident.
If the malicious JSON feed has been restored, a currently clean response only tells us what the endpoint is delivering now.
It does not prove what was delivered yesterday.
It does not prove that a rogue administrator account was never created.
It does not prove that a webshell was not installed.
And it certainly does not prove that an attacker who gained access did not make additional changes.
Security teams must therefore investigate historical activity rather than relying exclusively on the current state of the vendor infrastructure.
Deep Analysis: How the Attack Chain Works
Stage One: Vendor Infrastructure Compromise
The first stage reportedly involved obtaining write access to a storage bucket used by the vendor.
Once attackers gained this capability, they could manipulate content that downstream customers trusted.
This is a classic example of why cloud storage permissions should be treated as production security boundaries.
Stage Two: Poisoning the Remote JSON Feed
The attackers allegedly modified a static JSON response used for promotional content.
Because the plugins expected the
The attack therefore avoided many traditional malware-detection assumptions.
Stage Three: Triggering the XSS Condition
The Biggop Library reportedly failed to properly escape attacker-controlled information.
The display_id parameter became an important part of the exploit chain.
The malicious response was therefore transformed from remote data into executable browser content.
Stage Four: Abusing the Administrator Session
The JavaScript executed while an administrator was authenticated.
This gave the attacker the ability to make requests using the administrator’s existing privileges.
The attacker effectively borrowed the
Stage Five: Creating a Rogue Administrator
The malicious script reportedly created an additional administrator account.
This created a more durable foothold than a single browser session.
Once the attacker had a privileged account, they could potentially return later without needing the original JavaScript injection.
Stage Six: Establishing Persistence
The reported w2.js payload could install a fake plugin and establish a webshell through emer-run.php.
At this point, the attack evolved from supply-chain exploitation into server-side persistence.
The remote JSON feed was only the initial access mechanism.
Useful Investigation Commands
Search for Suspicious PHP Files
Administrators investigating a potentially compromised WordPress server can begin with filesystem searches such as:
find /var/www/html -type f -name ".php" -mtime -90 -ls
This can help identify recently modified PHP files, although timestamps alone should never be treated as proof of compromise.
Search for the Reported Webshell Name
find /var/www/html -type f -name "emer-run.php" -ls
If this file exists unexpectedly, it deserves immediate investigation.
Search for Suspicious JavaScript
grep -RniE "w2.js|display_id|Biggop|Biggopti" /var/www/html/wp-content 2>/dev/null
This can help locate references associated with the affected ecosystem.
Search WordPress Administrator Accounts
Using WP-CLI:
wp user list --role=administrator
Review every administrator account and verify that each one is legitimate.
Inspect Recent WordPress Users
wp user list --fields=ID,user_login,user_email,roles,registered
Unexpected recently created privileged accounts should be treated as suspicious until proven otherwise.
Inspect Plugin Inventory
wp plugin list
Pay particular attention to unexpected plugins, recently modified plugins, and plugins that administrators do not recognize.
Search Web Server Logs
For Apache:
grep -Ei "wp-admin|wp-login|xmlrpc|emer-run|admin-ajax" /var/log/apache2/access.log
For NGINX:
grep -Ei "wp-admin|wp-login|xmlrpc|emer-run|admin-ajax" /var/log/nginx/access.log
Logs can help establish whether suspicious requests occurred during the suspected compromise window.
Do Not Immediately Delete Evidence
A common mistake after discovering a suspected compromise is to start deleting suspicious files immediately.
That can destroy valuable forensic evidence.
If the website is business-critical, preserve relevant logs, database backups, filesystem snapshots, and timestamps before making extensive changes.
The goal is not simply to make the suspicious file disappear.
The goal is to understand what happened.
Rotate Credentials After Containment
If compromise is confirmed, administrators should consider rotating:
WordPress administrator passwords
Hosting credentials
SFTP/SSH credentials
Database credentials
API keys
Cloud storage credentials
Deployment credentials
Security-plugin credentials
Changing passwords before removing persistence can be insufficient.
An attacker who retains a webshell or privileged account may simply regain access using the new credentials.
Why This Attack Matters Beyond WordPress
The deeper lesson is not limited to BdThemes.
Modern software is increasingly dependent on remote services.
Applications retrieve configuration from APIs.
Plugins download promotional information.
Websites load JavaScript from CDNs.
Applications consume cloud-hosted JSON.
AI systems call external APIs.
Developers depend on package registries.
Every one of these connections creates another trust boundary.
The more remote dependencies an application has, the more opportunities an attacker has to compromise something upstream.
What Undercode Say:
01. Trust Has Become an Attack Surface
The BdThemes incident demonstrates that trust itself can be exploited.
- The Plugin Did Not Need to Look Malicious
The malicious behavior could arrive through external content rather than an obviously modified plugin package.
- Remote Data Must Never Be Assumed Safe
JSON is data, but unsafe parsing can turn data into executable code.
04. Administrative Interfaces Are High-Value Targets
Attackers deliberately targeted the WordPress dashboard because administrators already possess powerful privileges.
05. XSS Can Become a Full-Compromise Problem
Cross-site scripting is sometimes underestimated, but authenticated administrative XSS can have devastating consequences.
06. Supply Chains Are Increasingly Dynamic
The traditional idea of supply-chain security focused heavily on software updates.
Modern attacks can instead target APIs, storage buckets, CDN resources, or remote configuration.
07. Cloud Storage Permissions Matter
A writable production storage bucket can become a software-distribution mechanism for attackers.
- The Vendor Is Not the Only Victim
Every customer connected to the compromised infrastructure becomes a potential downstream target.
09. WordPress Magnifies Small Mistakes
A vulnerable library embedded in a popular plugin can potentially affect thousands of independent websites.
10. Active Installation Counts Matter
The more installations a plugin has, the greater the potential blast radius of a supply-chain compromise.
11. Authentication Can Become an Attack Tool
The attacker did not necessarily need to steal an administrator’s password.
They could abuse an already-authenticated browser session.
12. Session Context Is Extremely Valuable
When malicious JavaScript runs inside an
13. Persistence Changes Everything
Creating a rogue administrator or webshell means the attacker can potentially survive after the original injection disappears.
14. Removing a Plugin Is Not Enough
Organizations need to determine whether attackers already established persistence before containment.
- Clean Infrastructure Does Not Equal Clean Endpoints
A repaired API cannot retroactively clean compromised WordPress installations.
16. Historical Investigation Is Essential
Security teams need to examine logs and account creation events covering the suspected attack period.
17. Hidden Accounts Are Especially Dangerous
If malicious accounts are deliberately concealed, ordinary administrative checks may fail.
18. Database Manipulation Raises the Stakes
Attackers who can alter how administrative data is displayed can make conventional incident response more difficult.
19. Security Tools Need Multiple Visibility Layers
WAF alerts, endpoint monitoring, filesystem integrity checks, database auditing, and authentication logs should complement one another.
- A WAF Alone Cannot Solve Supply-Chain Attacks
The malicious content may arrive through an apparently legitimate vendor endpoint.
- Developers Must Treat Remote Content as Hostile
Every external response should be validated, sanitized, and handled under the assumption that it could eventually be compromised.
22. Output Escaping Remains Fundamental
Basic secure coding practices can prevent an entire class of attacks even when upstream infrastructure is compromised.
23. Cloud Permissions Require Continuous Review
Storage buckets should follow least-privilege principles and should not provide unnecessary write access.
24. Vendor Security Is Customer Security
A developer’s infrastructure can become part of the security perimeter of every customer using its products.
25. WordPress Administrators Need Better Visibility
Site owners should know which plugins are installed, which administrators exist, and which files changed recently.
26. Unexpected Administrator Accounts Should Trigger Alerts
Creating a new privileged user is one of the strongest signals of possible compromise.
27. Webshell Detection Should Be Standard
Unexpected PHP files deserve investigation, particularly in plugin and upload directories.
- Fake Plugins Are a Useful Persistence Mechanism
Attackers can disguise malicious functionality as something that appears to belong inside WordPress.
29. Supply-Chain Attacks Can Be Quiet
The absence of obvious malware or a malicious plugin update does not mean the environment is safe.
30. Remote APIs Need Security Monitoring
Organizations should monitor unusual changes in critical vendor endpoints where possible.
31. Developers Need Software Bills of Materials
Understanding dependencies helps security teams identify which applications could be exposed when a component is compromised.
32. Third-Party Risk Is No Longer Optional
A website may be secure internally while depending on an insecure external service.
- The Attack Chain Shows Why Defense-in-Depth Matters
Breaking any one stage—API integrity, XSS execution, privilege escalation, persistence, or outbound communication—can limit the attack.
34. Browser Security Matters Too
The
35. Administrators Should Avoid Unnecessary Dashboard Exposure
Highly privileged accounts should be used carefully, especially on environments containing numerous third-party plugins.
36. Security Teams Should Monitor Privileged Actions
Account creation, plugin installation, role changes, and unexpected file modifications deserve high-priority monitoring.
37. Third-Party JavaScript Deserves Suspicion
Remote scripts and dynamically generated content can introduce risks that static code review will miss.
38. The Incident Fits a Larger Trend
Recent software attacks increasingly target trusted ecosystems rather than directly attacking the final victim.
39. WordPress Security Is Becoming Supply-Chain Security
Protecting a WordPress site now means considering plugins, APIs, libraries, vendors, hosting infrastructure, and remote services together.
40. The Biggest Lesson Is Simple
Never allow trust to replace verification.
The BdThemes incident is a powerful example of how a seemingly harmless promotional feature can become a weapon when an attacker controls the data behind it.
✅ The BdThemes Products Were Removed From WordPress.org
The supplied report states that the affected products were removed from the WordPress.org plugin directory on August 8 pending investigation.
That is consistent with the described containment response and is an important distinction from permanently deleting the software from every customer website.
✅ The Attack Relied on a Remote JSON Feed
The central technical claim is that attackers poisoned a remote JSON data stream consumed by an administrative component.
This is significant because it explains how malicious behavior could be delivered without requiring every victim to manually install a new malicious package.
✅ The Attack Could Abuse an Authenticated Administrator Session
The reported exploitation chain involved JavaScript executing within the context of a logged-in administrator.
That makes the vulnerability substantially more serious than a simple public-facing XSS issue because the browser session could carry administrative privileges.
⚠️ Compromise Should Not Automatically Be Assumed on Every BdThemes Installation
The existence of an affected vulnerability or poisoned endpoint does not prove that every installation was compromised.
Site owners should instead investigate administrator accounts, plugin changes, filesystem activity, web-server logs, and other indicators during the suspected campaign period.
⚠️ A Clean API Response Does Not Guarantee Historical Safety
The report says the poisoned endpoints were returning clean JSON after discovery.
That is a positive containment development, but it does not establish that websites were never compromised while the malicious content was active.
Historical investigation remains necessary.
Prediction
(+1) Supply-Chain Security Will Become a Core WordPress Requirement
The most likely positive development from incidents such as this is that WordPress developers will increasingly treat remote APIs, cloud storage, promotional feeds, and third-party libraries as formal security boundaries.
Plugin developers are likely to place greater emphasis on strict output escaping, signed responses, integrity validation, least-privilege cloud permissions, and stronger monitoring of remote infrastructure.
Security vendors may also expand their detection capabilities beyond plugin files and version numbers to identify suspicious administrative account creation, unexpected PHP files, anomalous API responses, and malicious browser-side behavior.
The broader industry is gradually moving toward a more realistic model of application security: the software you install is only one part of the software you trust.
The Bigger Warning for WordPress Owners
A Plugin Can Be Clean While Its Supply Chain Is Not
The BdThemes incident illustrates a fundamental change in how modern websites must be defended.
Checking whether a plugin has the latest version is useful, but it is no longer sufficient.
A website can run legitimate software, use a legitimate administrator account, connect to a legitimate vendor, and still become compromised through a poisoned trusted communication channel.
That is what makes supply-chain attacks so dangerous.
The Dashboard Should Never Be Treated as Automatically Safe
WordPress administrators often assume that the dashboard is the safest part of the website because it is behind authentication.
But authentication does not neutralize malicious code.
If an
The BdThemes incident is therefore not merely a story about one WordPress vulnerability.
It is a warning about the modern web itself.
The New Security Rule: Verify Everything
Remote JSON should be treated as untrusted.
Third-party libraries should be treated as dependencies with risk.
Cloud storage should be treated as production infrastructure.
Plugin vendors should be treated as part of the organization’s attack surface.
And administrator sessions should be treated as high-value credentials even when no password has been stolen.
The attackers behind this campaign reportedly did not need to smash through the front door.
They found a trusted window, poisoned what was coming through it, and waited for an administrator to walk into the room.
That is the real lesson from the BdThemes compromise: in modern software ecosystems, the most dangerous code may not arrive looking malicious at all—it may arrive carrying the name of someone you already trust.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.bleepingcomputer.com
Extra Source Hub (Possible Sources for article):
https://www.linkedin.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
