How dxw protected clients from a recent WordPress supply-chain attack
One of our security hardening practices is that we treat site code as essentially immutable
This month has seen another very serious supply-chain attack on WordPress users who had one or more of the 26 plugins that used to be owned by essentialplugins. This affected some sites hosted by dxw, but thanks to our security practices, none of our sites were damaged by the attack.
The initial incident
On 8 April one of our automations found that a plugin we installed on several of our client sites had been withdrawn by WordPress from the plugin library due to a security incident. On the admin dashboard of sites with this plugin a notice had appeared from the WordPress Plugin Team:
‘We would like to inform you that several plugins from the author “essentialplugin” have been reported by the community as not compliant with the guidelines. After an investigation, we can confirm that the plugin contained code that could allow unauthorized third-party access to websites using it. …’
We immediately opened an incident, following our publicly documented procedures for security events. Within an hour, we had completed an investigation and removed the relevant plugins from all sites we host and shortly afterwards we had contacted all affected clients to let them know what had happened, and how we had mitigated the incident.
So, what happened?
Anchor, another WordPress host, has very helpfully documented the issue relating to essentialplugin in a lot of detail, following their own very careful investigation.
The gist of the timeline is that essentialplugin supplied a number of WordPress plugins to the public WordPress plugin ecosystem, and in 2025 the vendor sold their suite of plugins to a new owner.
In August 2025 the new owner planted a backdoor in the purchased plugins and in 5-6 April 2026 the backdoor was weaponised, by planting malware in sites that had the plugins installed. On 7 April the WordPress Plugins Team permanently closed all essentialplugin plugins, and on 8 April, the day we opened the incident at dxw, WordPress pushed an update to the plugins which removed the malicious code.
How did the attack work
According to Anchor, compromised sites made a remote request to a server under the control of the attacker to download a backdoor which was designed to look like standard code in WordPress Core to handle site comments. This then injected code into wp-config.php which is the WordPress file that handles configuration, including security related configuration. This configuration is something that could not be fixed by the update to the plugins that the WordPress Plugin Team published.
In affected sites, the injected malware was then able to send SPAM, redirect site visitors elsewhere, and anything else it wanted, all the time keeping itself hidden from site administrators.
Why dxw clients were not affected
dxw has been hosting sites for government and third sector for nearly 14 years now, and we’ve always had a security-first approach to managing client sites. One of our security hardening practices is that we treat site code (including configuration files such as wp-config.php) as essentially immutable and we do not allow plugins to write to arbitrary locations in the filesystem.
For that reason, although some of our sites had the initial “bad” code, the actual compromise could not be carried out by the attacker, and our sites were safe.
This meant we could safely investigate what had happened, remove the affected plugins and let clients know, without having to perform a full scale rollback of any sites.
Supply chain security
As Anchor hosting notes, this is not the first time that a buyer has purchased a plugin, or multiple plugins, in order to install malware on user systems. If you want to target a large number of end-users at once, WordPress constitutes over 40% of the web, and plugins with a very large number of installs represent an easy vector of abuse for attackers. The original plugin authors have already done the hard work of creating the plugins, marketing them, building trust with a large user base, and so it couldn’t be easier to compromise the supply chain.
Unfortunately, it’s difficult for ecosystems to protect against this sort of compromise, but happily the WordPress Plugin Team acted quickly to revoke the attacker’s access to the plugin ecosystem, then remove the malicious code and notify users. Ideally though, every time a plugin has its ownership transferred, the next update would be marked as a major version update and flagged for review. Of course, manual review is not perfect, but this way the malicious code could have been caught back in 2025, before it was pressed into use this April.
Choosing a secure hosting provider
WordPress hosts essentially come in 2 distinct flavours:
- cheaper hosting companies that manage a very large number of sites “at scale” and will largely leave you to manage your own plugins and themes, and
- hosts for bespoke sites like dxw who are more expensive but provide a highly personalised service and pro-actively manage your site security for you.
No risk appetite is right for everybody and no price point is right for everybody, but when you choose a hosting provider you need to keep security at the top of your mind.
If you go with a cheaper host, our advice would be to turn on automated plugin and theme updates as well as WordPress Core updates, and leave them on even if they break your site. Make sure you always have backups available, so you can roll back manually if you ever do have a breach.
If you go with the second, security-first approach, then much of this work should be done for you. But you should still look for the usual marks of high quality security provision, such as Cyber Essentials Plus, ISO-27001, and so on. If the hosting company publishes their incident response process then all the better, but if not you can ask them how they manage supply chain security, and how they deal with situations like this one. And if you are looking for reliable, secure WordPress hosting, please do get in touch.