GravityKit products now give you a stronger reason to trust what you install

When you install a plugin, you implicitly trust that the code arriving on your site is the code the vendor intended to ship. WordPress doesn’t verify that — it downloads the package, unpacks it over your existing files, and moves on.

As of April 2026, GravityKit-managed product installs and updates delivered through our update system are cryptographically verified before WordPress unpacks them. If a package has been changed anywhere along the way, the installation is blocked. The check happens quietly in the background, requires no configuration, and adds another layer of protection between our release process and your website.

The update path itself has become a target

Keeping software up to date is still one of the best things a site owner can do. But updates only help if the package that reaches your site is the package the vendor actually released. Recent supply-chain incidents have shown that this is no longer a safe assumption. Three from the past few months alone:

• March 2026: WowShipping Pro was compromised at the source, with the paid edition shipping malicious code that captured admin logins and exfiltrated 2FA secrets — including from the very 2FA plugins customers had installed to defend themselves.
• March 2026: Outside of WordPress, a malicious release of Axios — one of the most widely used open-source JavaScript libraries in the world — added a fake dependency that ran during install and downloaded a second-stage remote-access payload.
• April 2026: Smart Slider 3 Pro customers received a trojanized build through the vendor’s official update channel after its infrastructure was compromised. Roughly 900,000 paying Pro sites were exposed; the free WordPress.org edition was untouched.

They point to the same broader risk: trusted software distribution paths have become attractive targets. Customers and developers can do the expected thing — install or update from an official source — and still receive code that has been compromised upstream. As Hedgehog Security wrote of the Smart Slider customers, they “did exactly the right thing by keeping their plugins up to date”, and yet were punished for good hygiene because the supply chain was compromised upstream.

Somebody had to put a signature on a paid WordPress plugin. We’re surprised it took until 2026, but happy to lead the way.

We put a seal on every package

Every GravityKit package we publish now has cryptographic signature metadata recorded alongside it. Think of it like a tamper-evident seal for the release: the signature belongs to that exact package, and only that package. If the file changes after we sign it (even by a single byte), the signature no longer matches, and the install is refused.

This is not a novel idea. For example, WordPress core itself has had signature-verification infrastructure since 2019, but it doesn’t actually verify production updates today, and it never extended to plugins or themes. Before starting this work, we also reviewed what other vendors were doing, and to the best of our knowledge, none of them currently ship signed releases with install-time verification as part of their normal update flow (if you know of one that does, we’d love to hear about it!). We chose to close that gap by rolling out a solution that’s based on industry best practices and tightly integrated with WordPress’s own update flow.

Built on proven cryptography

The cryptography behind it is conventional too. We use Ed25519, a modern digital-signature algorithm supported by widely used systems and protocols, including SSH and TLS 1.3. It is robust, well-understood, and fast enough that the verification step adds no perceptible delay to an update.

Verification happens after the ZIP is downloaded to a temporary location but before WordPress unpacks or installs it, and it’s handled by Foundation (the shared library that ships with every GravityKit product to handle licensing, settings, and product infrastructure). Foundation hooks into the update flow at the earliest point it can, checks the file WordPress is about to unpack, recomputes its fingerprint, and compares it to the signature we issued. If another component has already supplied the downloaded file, Foundation verifies that file before allowing WordPress to continue. If anything is off, the file is deleted and the install never starts. Nothing unpacks, nothing overwrites your existing plugin. A clean update looks exactly like it always did; a tampered one is refused before it can do any harm.

One update protects them all

We started with GravityView 2.57 on April 16, 2026, and the rollout is now reaching the rest of our product line. You don’t have to wait for every product to update individually for the protection to apply, though. When you have several active GravityKit products on a site, the newest active copy of Foundation becomes the active GravityKit framework on that site — so the moment one active product updates to a build with the new signing layer, Foundation starts verifying future GravityKit-managed updates on that site, not just updates for that one product. One update can bring the whole GravityKit installation up to the new protection level.

We also planned for the day a signing key is ever compromised. There is a separate, independently signed revocation list that Foundation checks on a regular basis. If we ever need to invalidate a signing key, we can do it relatively fast and without shipping a new version of Foundation. A hostile network can’t forge a clean revocation list. And once a customer site has seen a key revoked, Foundation remembers that locally, so an older signed list cannot make that key trusted again.

Most importantly: there’s nothing to configure on your side. No new setting, no checkbox in your dashboard. You update our products the way you always have, and Foundation handles verification automatically.

What signing doesn’t fix

Signing closes one important door between our release process and your filesystem: a package changed after signing should not install. There are other doors signing doesn’t close, and they need their own defenses: source-code compromises that happen before we sign, post-install tampering on a server that has already been breached, and weaknesses elsewhere in the WordPress ecosystem. For the post-install half of that problem in particular, file-integrity scanners like Wordfence, Sucuri, or Solid Security are the right tools, and worth running on any production WordPress site.

Beyond that, the usual baseline still matters: two-factor authentication (2FA) on your WordPress and GravityKit accounts, backups you trust, strong admin passwords, removing administrators who no longer need access, being selective about any third-party code you run, and patching when updates ship. The Smart Slider story is an argument for more aggressive patching, not less, because the right response to “good hygiene can be punished” is better vendor signing, not worse hygiene.

Our customers trust us with their websites, so we see this as our responsibility. We’re the first paid WordPress plugin to do this, but I hope we’re not the last.

Zack Katz, Founder, GravityKit

Code signing isn’t the finish line

Code signing isn’t the finish line. It is a layer we shipped because the channel between our release process and your site is one important part of the supply chain we can harden ourselves, on a timescale we control. Beyond this change, we’re working on other hardening steps (most of them invisible to customers) and watching the broader ecosystem. If WordPress core, the FAIR protocol, or any shared signing model emerges that fits plugin distribution outside WordPress.org, we would rather build on common infrastructure than maintain our own verifier forever.

Until then, this is the part of the supply chain we control, and we’ll keep hardening it. GravityKit customers already trust us every time they update, and this added safeguard just makes that trust a little less implicit and a lot more verifiable. We hope other plugin vendors ship the same.

Want the architecture details—how verification slots into WordPress’s update flow, how we manage and rotate signing keys, and what the model deliberately doesn’t try to solve? Read the technical overview.

Have questions about the new verification flow? Reach out to support.