Meta News

A supply chain compromise affecting WordPress plugin developer BdThemes has demonstrated an unusually effective way to attack websites without modifying the plugins themselves. Rather than injecting malicious code into packages distributed through WordPress.org, the attackers compromised external infrastructure trusted by the plugins and manipulated remote JSON data that was automatically retrieved whenever administrators accessed their dashboards.

The attack affected seven BdThemes plugins, including Element Pack Addons for Elementor, which alone has more than 100,000 active installations, as well as Live Copy Paste for Elementor and Ultimate Store Kit, each with more than 6,000 installations. WordPress temporarily closed the affected plugins to new downloads on August 7 and 8 while conducting a full review.

What makes the incident particularly significant is its architecture. There was no malicious WordPress.org update that administrators needed to install. Sites could be compromised while running legitimate plugin code because that code continued trusting information delivered by infrastructure controlled by the vendor.

The compromise centers on an internal BdThemes component called Biggopti, included with the affected plugins. Biggopti retrieves promotional information from BdThemes infrastructure and displays banners inside the WordPress administration interface.

Those promotional records are obtained as JSON data stored in a DigitalOcean Spaces bucket. Researchers at Wordfence discovered that the component did not adequately sanitize thedisplay_idparameter contained in responses from the Sigmative API, creating a cross-site scripting vulnerability.

On its own, the flaw received a relatively modest CVSS score of 5.4. In the context of a supply chain compromise, however, its practical impact was substantially greater. Attackers apparently obtained write access to BdThemes’ cloud storage and replaced legitimate JSON records with malicious ones. When an administrator openedwp-admin, the trusted plugin downloaded the poisoned data and executed attacker-controlled JavaScript inside the administrator’s browser.

This is an important distinction from a conventional plugin compromise. The malicious payload existed outside the installed WordPress package, allowing attackers to change their behavior remotely without publishing another version or altering files already stored on affected servers.

Executing JavaScript within an authenticated WordPress administration session provides attackers with a powerful position. The browser is already operating with the administrator’s permissions, meaning malicious code can interact with functionality that would normally remain inaccessible to an unauthenticated visitor.

Wordfence found that the principal payload, a JavaScript file calledw2.js, first contacted attacker-controlled command-and-control infrastructure to determine whether the targeted site should be compromised. Selected victims were then subjected to a series of actions intended to establish persistent administrative access.

The script created a rogue administrator through the WordPress REST API and downloaded a fake plugin containing a PHP web shell. That web shell subsequently installed additional components into WordPress’s Must-Use plugins directory, giving the attackers persistence beyond the original browser-based compromise.

At that point, what began as an XSS vulnerability in a promotional banner system had effectively become remote administrative control over the WordPress installation.

The persistence mechanisms reveal that the campaign was not simply intended to create temporary access. One malicious module installed a “magic login” backdoor capable of providing unauthenticated administrative access through a specially crafted URL parameter.

Another component attempted to conceal the compromise.

The malware intercepted WordPress database queries so that attacker-created administrator accounts would not appear normally within the site’s user-management interface. It also manipulated the displayed user count so administrators would be less likely to notice that additional accounts existed.

This combination of access and concealment is particularly dangerous for incident response. A website owner examining the WordPress dashboard might see nothing obviously suspicious even though an unauthorized administrator and persistent backdoor were already present.

Simply correcting the vulnerable promotional component would therefore not necessarily clean an already compromised installation. Once the secondary payloads were deployed, the attackers had created mechanisms capable of surviving independently of the original attack vector.

Researchers discovered another payload,x.js, hosted directly on the plugin developer’s infrastructure. Rather than relying on randomly generated credentials, this version mathematically derived the malicious administrator username and password from the victim site’s hostname.

That design gave the attackers an operational advantage: they did not necessarily need to maintain a centralized database containing credentials for every compromised WordPress site. The same deterministic algorithm could reproduce the correct credentials whenever access was required.

For defenders, however, that predictability also provides an opportunity. Incident responders can calculate what malicious username and password should have been generated for a particular domain and search directly for the corresponding account.

The technique illustrates the level of planning behind the campaign. The attackers were not merely exploiting an XSS flaw opportunistically; they were constructing a scalable mechanism for establishing and maintaining access across potentially large numbers of WordPress installations.

The incident also highlights the limitations of assessing vulnerabilities exclusively through severity scores.

A CVSS score of 5.4 would normally place the underlying XSS vulnerability in the medium-severity category. That classification makes sense when the flaw is considered in isolation: exploitation requires control over data supplied by the trusted API.

But the attackers apparently achieved precisely that prerequisite by compromising BdThemes’ upstream infrastructure.

Once control of the API data was combined with the XSS vulnerability, the security impact changed dramatically. The malicious JavaScript executed automatically whenever an authenticated administrator accessed WordPress, providing the context required to create privileged accounts and install server-side malware.

The episode demonstrates why exploitability depends on architecture as much as vulnerability severity. A moderate weakness located across a powerful trust boundary can become considerably more dangerous when another component of that boundary fails.

The presence of malicious JSON records and secondary JavaScript directly within BdThemes-controlled infrastructure strongly suggests that attackers obtained access to the vendor’s cloud storage credentials or internal systems, according to Wordfence.

That transforms the incident from a WordPress plugin vulnerability into a broader software supply chain attack.

The plugins behaved as their developers designed them to behave: they contacted the vendor’s infrastructure, downloaded data and processed it. The security failure occurred because the remote information was implicitly trusted even though it could influence code executing inside a privileged administrative context.

This architecture created a dependency that was not visible in the plugin package itself. Auditing the code downloaded from WordPress.org would not necessarily reveal malicious files because there were none. The dangerous content arrived later from infrastructure controlled by the vendor.

It is a reminder that the modern software supply chain extends well beyond package repositories. APIs, cloud storage buckets, update services, analytics systems and remotely delivered configuration can all become part of an application’s effective code path.

Researchers believe the command-and-control infrastructure used in the BdThemes campaign is related to two other recent WordPress supply chain incidents involving Advanced Responsive Video Embedder and OptinMonster.

Those campaigns similarly attempted to establish unauthorized administrative access using concealed accounts, plugins or authentication mechanisms. The recurring infrastructure and comparable techniques suggest a broader operation focused on obtaining persistent control over WordPress installations rather than a one-off compromise of BdThemes.

That pattern matters because persistent administrator access provides attackers with considerable flexibility. A compromised WordPress site can later be used for credential theft, malicious redirects, spam campaigns, malware distribution or additional infrastructure supporting other cyber operations.

The initial compromise therefore does not necessarily reveal the attacker’s eventual objective.

The most important lesson from the BdThemes incident is that software integrity can no longer be measured exclusively by examining the files installed on a server.

A plugin can remain unchanged while its behavior becomes malicious because it consumes dynamic information from external infrastructure. If that information reaches privileged application contexts without adequate validation, compromising the upstream service can effectively compromise every downstream installation.

For WordPress developers, remote API responses should consequently be treated as untrusted input even when they originate from infrastructure controlled by the same company. Data rendered inside administrative interfaces requires strict sanitization, and remote content should never be capable of silently becoming executable code.

The same principle applies well beyond WordPress. SaaS applications, mobile software and modern web platforms routinely retrieve configuration and content from remote services. Each external dependency creates another trust relationship that attackers can potentially target.

The BdThemes attack succeeded precisely because that relationship worked as intended. Trusted plugins contacted trusted vendor infrastructure and accepted what it returned. Once attackers gained control of one side of that relationship, they inherited a path into the other.

That is what makes this incident an important example of modern supply chain risk:the attackers did not need to poison the software package when they could poison the data the software already trusted.