Why WordPress plugins are not cryptographically signed

When you install a plugin on a WordPress site, nothing checks that the file came from the person whose name is on it. Not the directory, not your site, not your host. The package arrives over HTTPS from wordpress.org, and HTTPS tells you the connection was not tampered with in transit. It says nothing about who put the file there.

Every other major package ecosystem has fixed this or is fixing it. The odd part is that WordPress has had most of the machinery sitting in core since 2019.

WordPress already ships signature verification

In WordPress 5.2, Paragon Initiative landed Ed25519 signature verification for plugin and theme installs and updates, along with sodium_compat, a pure PHP polyfill that made modern cryptography available on the older PHP versions WordPress still supported.

The code is still in core. It runs. If the update server hands it a signature, it verifies it.

It has never stopped a single install.

Soft verification means it never says no

The implementation is what the tickets call soft verification. It checks the signature if one is offered, records whether the check passed, and then installs the package either way. A failed check produces a note, not a refusal.

Trac ticket 39309, which covers making verification actually enforce, was accepted years ago on the basis that package signing will be added eventually. It has been sitting in the "Future Release" milestone for seven years.

That sounds like neglect and it mostly is not.

Turning it on breaks everything at once

Think about what happens the day core starts rejecting unsigned packages.

Nothing in the directory is signed. Around 68,000 plugins, none of them carrying a signature, all of them installing fine this morning. Flip enforcement on and every one of those installs fails. So enforcement cannot come before signing, which means someone has to sign roughly 68,000 packages first, and that requires every one of those maintainers to hold a key, protect it, and use it on every release. A good share of those maintainers have not logged in for four years.

You can try to route around it. wordpress.org could sign everything centrally on the maintainers' behalf, which is achievable and also answers a different question than the one worth asking. A central signature proves the file came from wordpress.org, which you already knew from the TLS connection. It does not prove the file came from the author, and author identity is the thing that failed in the supply chain attacks of April 2026, where plugins changed hands and the new owner shipped a backdoor through the perfectly legitimate channel.

So the useful version needs per-author keys, which needs key management, key recovery, key rotation, and revocation, for tens of thousands of people, most of whom did not sign up for any of that. That is the actual blocker. It is a distribution and social problem wearing a cryptography costume.

Gossamer tried to solve it properly

Paragon Initiative came back at it from the other direction with Gossamer: a public key infrastructure with no certificate authorities, designed for WordPress and Packagist together, with a transparency log so key changes were publicly auditable rather than taken on trust. It had its own Trac ticket, 49200, proposing that developers sign their own plugins.

Scott Arciszewski wrote it. He is the person who got a cryptographically secure random number generator into WordPress 4.4 and sodium_compat into 5.2. On this specific problem there is nobody better qualified in the PHP world.

It did not land. The libgossamer repository was archived by its owner on 19 September 2025, with 37 stars and two forks. The author has since said he is not helping WordPress in any capacity until further notice.

In his own retrospective he named two reasons, and neither is technical. The team never got much practice at marketing an idea. And Sigstore, he noted, already does about two thirds of what Gossamer did.

Every other package ecosystem solved this

While WordPress stalled, the rest of the world converged on the same answer.

Sigstore is the piece Arciszewski was pointing at. Rekor is a public, append-only transparency log. Fulcio issues short-lived signing certificates tied to an identity you already have, so the log records who signed rather than just which key was used, and nobody has to store a long-lived private key. SLSA describes build provenance, linking an artifact back to the source commit and the builder that produced it. in-toto is the envelope it all travels in.

PyPI, npm, crates.io, RubyGems and NuGet have all adopted it.

The part that matters for WordPress is what Fulcio removes. Earlier I said the real blocker is key management for tens of thousands of maintainers who never signed up for it. Keyless signing deletes that problem rather than solving it. The author does not generate a key, store a key, rotate a key, or recover a key. Their build system proves who it is using an identity they already have, a GitHub account or similar, gets a certificate that expires in minutes, signs with it, and throws it away. What lands in the log is the identity, not a secret anybody has to protect for a decade.

That is the difference between the 2019 design and the 2026 one. Gossamer and the core implementation both assumed authors would hold long-lived keys, because in 2019 that was the only option on the table. Roughly 68,000 maintainers holding private keys is not a plan. Roughly 68,000 maintainers already having a login is just a description of the world.

The close-to-home example is Packagist, which is the same language and largely the same people. In May 2026 it published a roadmap covering trusted publishing through OIDC, SLSA provenance, Sigstore attestations, immutable artifacts, a minimum release age, and client-side verification inside Composer itself. A public transparency log for security events is already live, funded in part by the German Sovereign Tech Agency. Private Packagist has offered Sigstore attestations since September 2025. The PHP tooling exists and passes Sigstore's own conformance suite.

None of that required WordPress to solve a novel problem. It required somebody to fund and operate it.

What would actually have to happen

Three things, roughly in this order, and none of them is writing a signature verifier because that already exists.

Somebody publishes ownership changes. Signatures prove a key signed a file. They do not tell you the key changed hands last Tuesday. Until the registry publishes who holds publish rights and when that changed, a valid signature from a new owner looks identical to a valid signature from the original author.

Signing becomes opt-in and additive before it is ever mandatory. Authors who want to sign can, clients record what they saw, and nothing breaks for the 68,000 who do not. That is how Packagist is sequencing it, and it avoids the flag-day problem entirely.

The client learns to hold an update, not just report on one. WordPress auto-updates plugins with no human in the loop. A verification result that arrives after the update has run is a post-mortem. In June 2026, wordpress.org introduced a six hour cooldown before releases reach the update API, and Packagist added a minimum release age in the same quarter, so two ecosystems arrived at the same control independently.

In the meantime, the practical move for a site owner is unchanged, and it is the unglamorous one: know what you have installed, know who maintains it, and notice when that changes. How to check whether a plugin is still maintained covers the signals that are available today, all of which are weaker than a signature and all of which are better than nothing.

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.