Why WordPress still cannot tell you who published your plugins

In April 2026 someone bought 31 WordPress plugins on Flippa. Their first commit after taking ownership was a backdoor. It sat quietly for about eight months before it woke up. The same week, a separate vendor had its development environment breached and shipped malicious code to more than 200,000 sites through its own legitimate release channel.

In both cases every signature was valid, because there were no signatures at all. And in both cases the code arrived through exactly the channel it was supposed to arrive through. That is worth sitting with.

Neither of those was a clever attack. Both were a paperwork attack. Somebody acquired the right to publish, and the right to publish is the whole game.

So I spent a couple of days on an obvious question: why can WordPress, which runs about 40 percent of the web, not tell you who published the code on your site or when that changed? The answer turns out to be well documented, slightly sad, and not at all about cryptography.

Three attempts, none of which failed on the crypto

2019: core package signing. Paragon Initiative got Ed25519 signature verification into WordPress 5.2, along with the sodium_compat library that made it possible on older PHP. It shipped. It is still there. It is also still soft, meaning it checks a signature if the update server provides one, reports the result, and then installs the package anyway. Trac ticket 39309, which tracks making it actually reject anything, has been sitting in "Future Release" for seven years.

The reason is not laziness. If you flip soft verification to hard, every unsigned package in the directory stops installing overnight, which is all of them. Nobody has a safe path from here to there.

2019 to 2025: Gossamer. Same team, bigger idea. A public key infrastructure with no certificate authorities, built specifically for WordPress and Packagist, with a transparency log so that key changes were publicly auditable. Scott Arciszewski, the person who got a proper random number generator into WordPress 4.4, wrote it.

It never landed. The GitHub repository was archived on 19 September 2025. Thirty seven stars. The author has since said he is not helping WordPress in any capacity until further notice. In his own retrospective he noted two things: they never got much practice at marketing, and Sigstore does about two thirds of what Gossamer did.

2024 to 2026: FAIR. The most serious attempt. Federated and Independent Repositories, launched under the Linux Foundation in June 2025 with real architecture behind it: W3C decentralized identifiers instead of wordpress.org slugs, Ed25519 signing, federated repositories so no single party could cut anyone off, and a labeling system borrowed from Bluesky's moderation design.

In February 2026 the founders stepped away. Joost de Valk wrote it up plainly. Hosting companies would not fund it, because "investment means commitment. It means cost. It means stepping into political tension." His conclusion is the line I keep coming back to:

If the ecosystem won't fund neutrality, neutrality won't materialize.

FAIR still exists and still ships. It has largely moved to TYPO3, where European digital sovereignty money and the EU Cyber Resilience Act give it a buyer that WordPress never provided.

All three needed permission from someone who does not carry the loss

Three attempts. Three working implementations. Zero adoption failures caused by the cryptography.

What all three have in common is that they needed permission or money from somebody who does not personally carry the loss when a plugin gets backdoored. Core signing needed the core team to break every existing install. Gossamer needed publishers to adopt signing voluntarily. FAIR needed hosts to fund infrastructure that would benefit their competitors equally.

The people who actually eat the loss are the site owner and the agency who has to explain it. None of the three attempts ever asked them for anything.

Maintenance signals need evidence

Correction, September 29, 2026: The original sample figures, install-band chart, detection funnel and associated anecdotes have been withdrawn pending verification of the underlying dataset. The available article copies contain inconsistent statistics. They do not support the published quantitative conclusions.

A release date, support queue or change of committer can prompt a closer review. None independently proves abandonment, a transfer of ownership or malicious activity. Compare the actual changes with the plugin's purpose and check the evidence before making an allegation.

You cannot see a transfer of rights from outside

SVN records commits. A change in the account making commits does not by itself prove an ownership transfer, and a commit history alone cannot establish the complete current access list. Treat maintainer identity, authority to publish and artifact verification as separate questions.

That is a small conclusion with an annoying consequence. The problem is not that nobody has built the technology. It has been built three times. The problem is that the one piece of information that would make it work is held by the registry, and no registry in the CMS world currently publishes it. Packagist is closest, with organizational package ownership on its roadmap alongside Sigstore attestations and trusted publishing, funded in part by the German Sovereign Tech Agency. WordPress has nothing comparable planned that I can find.

What I am doing with this

Nothing, commercially. I am not selling a product here and there is nothing to sign up for.

The earlier research claims remain withheld until their source data and method can be verified. I am not offering an unverified list of plugins as a security finding.

Two things I would genuinely like to be wrong about. The first is that existing safeguards address more of this risk than the public evidence makes clear. The second is that somebody at Automattic or in the plugins team is already planning to publish ownership change events, in which case most of this becomes moot and I will be delighted.

If neither is true, then the next version of the April attack is going to be found the same way the last one was, which is afterwards.

Disclosure. MaxtDesign builds and sells WordPress plugins, and we have been looking at whether there is a business in package provenance and verification. So we have a stake in the argument above. We are not building a competing package manager. If we ever run a verification service, our own plugins are permanently out of scope for it, and that exclusion gets stated publicly rather than promised quietly.