The 2026 WordPress supply-chain attacks: what happened, and what each one teaches

One came through a change of ownership. The other came through a vendor's own build pipeline. The difference matters, because the defences are different and no single tool covers both.

This page is a dated record. Where something is disputed or unknown, it says so.

Incident one — the Flippa portfolio, April 2026

A buyer acquired a portfolio of more than thirty WordPress plugins through Flippa, the website marketplace, for a reported six-figure sum. The portfolio included the Essential Plugin range, with a combined install base reported at around 400,000 sites.

The buyer's first commit after taking over was a PHP deserialization backdoor.

The dormancy is the part worth sitting with. The backdoor was planted in August 2025 and did nothing for roughly eight months. In April 2026 it activated, injecting cloaked SEO spam across every site running the affected plugins. On 16 April 2026 the WordPress Plugins Team closed all 31 plugins in a single day.

Why nobody noticed

Nothing about the transfer was announced. WordPress.org does not review plugin ownership transfers and does not notify the sites running a plugin when its ownership changes. The plugins kept their names, their directory listings, their install bases and their update channel. To every site running them, the malicious release arrived as an ordinary update.

The ownership transfer itself was visible in public data from the day it happened — the listed author changed, the contributor list changed, and an unfamiliar username began committing. Anyone comparing that record against the previous week's would have seen it. Nobody was comparing.

Incident two — ShapedPlugin Pro, June 2026

Attackers compromised ShapedPlugin's own build and distribution pipeline and shipped backdoored updates of its Pro plugins between April and June 2026. It was assigned CVE-2026-10735.

The payload was considerably more aggressive than the first incident's: stolen credentials and 2FA codes, wp-config.php contents exfiltrated, WooCommerce order data taken. It hid itself from the WordPress admin plugin list, registered a REST API backdoor accepting arbitrary file writes, bundled Tiny File Manager and Adminer for direct file and database access, and installed a webshell driven by URL parameters with a hardcoded login bypass.

Ownership monitoring would not have caught this one

There was no transfer. The vendor did not change hands, the committer list did not change, and the people publishing releases were the same people as the month before. The provenance record looked entirely normal throughout, because the provenance was not what broke — the pipeline was.

Being clear about this matters more than claiming broad coverage. A tool that monitors ownership has nothing useful to say about a compromised build server. Touchstone would have shown nothing, and says so on its own front page.

What the two have in common

Neither was a vulnerability. Nothing in either case was a bug a scanner could have matched against a database, because in both cases the code did precisely what its author intended.

That is the structural problem. A vulnerability scanner compares your plugins against a catalogue of known-bad. Both of these arrived as new code, from the expected source, through the ordinary update channel, before any catalogue had heard of them. Most affected sites were running a scanner the entire time.

The window in which either was preventable was before the malicious release installed itself — and in the first case, that window was eight months long.

The gap WordPress already acknowledges

This is not an outside criticism. There is an open ticket on the WordPress meta tracker, #5509, Notify users of changes to plugin ownership. It is filed, it is discussed, and it is unresolved. WP Tavern has covered the question editorially more than once.

So the position today is: plugin ownership transfers are permitted, unannounced, unreviewed, and invisible to the sites affected. Everyone involved knows it.

What you can actually do

For the ownership case. The data is public. Every plugin's directory page lists its author and contributors, and its SVN repository carries the full commit history including the username behind every commit. You can read both by hand. Doing it once for one plugin is easy. Doing it weekly for forty plugins across twelve client sites is not, which is why nobody does it, which is why the April incident ran for eight months.

For the pipeline case. Ownership data will not help you. What helps is staged updates rather than automatic ones, a delay between a release and its installation on production, file-integrity monitoring, and reading the changelog of anything that ships a surprise release.

For both. Reduce the plugin count. Every plugin is a party you have chosen to trust with code execution on your site, and the transfer of that trust does not require your consent or your knowledge.

Timeline

Date	Event
August 2025	Backdoor committed to the acquired plugin portfolio
April 2026	Backdoor activates; cloaked SEO spam injected
16 April 2026	WordPress Plugins Team closes 31 plugins
April–June 2026	ShapedPlugin Pro ships backdoored updates
June 2026	ShapedPlugin compromise disclosed, CVE-2026-10735