A buyer known as “Kris” purchased the Essential Plugin business on Flippa for a six-figure sum in early 2025. The acquisition covered more than 30 WordPress plugins with hundreds of thousands of active installations. Within months, the new owner inserted a PHP deserialization backdoor across all of them. The malware sat dormant for eight months before activating on April 5-6, 2026. WordPress.org closed all 31 affected plugins on April 7.
The attack is technically notable in two ways. First, the dormancy period. Eight months is long enough that any security audit conducted at acquisition or shortly after would have found clean code. The payload was injected gradually and designed not to trigger. By the time it activated, most site owners had received multiple routine plugin update notifications across those eight months — any one of which could have installed the backdoor. Second, the command-and-control infrastructure used an Ethereum smart contract to resolve its C2 domain. Traditional domain takedowns — registrar seizure, DNS block — do not work against a contract on a public blockchain. The malware downloaded a backdoor file, injected code into wp-config.php, and then checked the blockchain for its instructions. Getting rid of the domain doesn’t help if the C2 address is immutable on-chain.
This attack pattern is different from the Axios supply chain compromise earlier this year, which exploited social engineering against an existing maintainer. The acquisition attack is more systematic. Flippa and similar plugin marketplaces have no mechanism to review plugin ownership transfers, flag suspicious acquisition activity, or trigger enhanced code review when commit access changes hands. A buyer with a legitimate-looking profile, a plausible business rationale, and enough cash can acquire a trust-earning plugin with a large install base and inherit the trust directly. The 2017 Display Widgets incident involved the same pattern, which means the platform has not fixed the underlying problem in nine years.
For anyone running WordPress, the immediate action is to check whether any installed plugins were in the affected set (full list in the Anchor Hosting post) and audit wp-config.php for injected code, particularly if backups show it changed during the April 5-6 window. Even after WordPress.org force-updated affected plugins to version 2.6.9.1, the injected wp-config.php modifications remained in place. Plugin deactivation and update are not sufficient; the config file needs manual inspection.
The broader implication is that plugin trust models based on install count and review history are broken for acquisitions. A plugin with 50,000 active installs and five-star reviews accumulated over five years can be purchased and weaponised in months. Any organisation treating WordPress plugin selection as a one-time decision rather than ongoing supply chain management is operating with a risk model that doesn’t account for this. The correct posture is to treat external plugins as third-party code with an unknown future ownership trajectory.